Opened 11 years ago
Closed 9 years ago
#22022 closed New feature (wontfix)
Allow field subclasses to require additional SQL
Reported by: | Marc Tamlyn | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Problem
In postgres, a number of data types require a specific extension to be installed. We have one instance of this in core at present, which is the postgis
extension. Our documentation recommends[1] (in postgres 9.1+) that you explicitly create the extension in your primary database by hand, and then we customise the _create_test_db
method on the postgis database backend to ensure the test database has the relevant extensions installed.
Other third party apps[2] recommend adding the extension to the template to ensure it's present in tests.
I wish to avoid adding a custom backend to d.c.postgres if at all possible, especially as using it in conjunction with gis should be permissible. Consequently, I'd like if possible for model fields to have pre_create_sql
to allow each individual field to create the extensions as needed. The same mechanism could also be used for a user defined custom field to create functions which could then be used as a custom transform object.
This feature will be useful for:
1) one part of the de-hack-gis project
2) hstore
3) citext, trigrams, generating uuids database side and other possible future features of d.c.postgres
I've written a draft patch[3]. It probably needs some work (hence patch needs improvement) but an initial review of the names and code layout would be useful.
[1] https://docs.djangoproject.com/en/1.6/ref/contrib/gis/install/postgis/#creating-a-spatial-database-with-postgis-2-0-and-postgresql-9-1
[2] http://djangonauts.github.io/django-hstore/#_running_tests
[3] https://github.com/django/django/pull/2266
Change History (3)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 10 years ago
Description: | modified (diff) |
---|
comment:3 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Marc on the pull request, "I'm going to give up on this concept in favour of manual Operations."
In principle, sounds like a reasonable proposition to me. There's clearly some discussion happening on the pull request, but I suspect that this will only shape the final form of the feature, not the base functionality.