On 5/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-05-26 at 01:53 -0500, Jacob Kaplan-Moss wrote: > > On 5/26/07, Justin Bronn <[EMAIL PROTECTED]> wrote: > > > We encountered a similar problem on the GIS branch. Specifically, the > > > OpenGIS specification requires that compliant spatial databases add > > > geometry columns by calling the stored procedure AddGeometryColumn() > > > after the table definition. > > > > > > The way we solved it was a bit different from your proposals. We > > > patched the management.py function get_custom_sql_for_model() to look > > > for a function on the field called "_post_create_sql." In our Field > > > subclass, GeometryField, we define a _post_create_sql method that > > > returns the needed SQL (a string). The field-generated SQL hitches a > > > ride on the output of the initial SQL data function that is already > > > called anyway. > > > > I'm a bit drunk right now, but I think this patch looks like a good > > idea. If nobody's got any objections and if it still seems like a good > > idea in the morning I'm thinking I'll apply this patch to trunk in the > > morning. It seems this feature will help a lot in custom field > > development. > > Yo, > > Did you think better of this, or haven't gotten around to it yet?
I hadn't heard back from Adrian yet; I want to make sure to have his OK. I'll let the GIS folks answer your question about _get_field_sql(); my impression is that PostGIS at least makes you declare GIS fields *after* you declare your table. Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
