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'm going to try and put to bed a lot of the custom field stuff that has
been floating around this week (it's mostly a documentation issue; 90%
of the pieces exist) and _post_create_sql() or something like it is one
of the missing pieces (for custom field creation).
I am wondering a little bit why this isn't _get_field_sql(), though.
That could be as part of the table construction phase, so you can insert
the SQL for the column directly into the CREATE TABLE statement, rather
than adding it after the fact. To be clear, I'm thinking that
_get_field_sq() would return something like
column_name INTEGER NOT NULL
and management.py would add the trailing comma if necessary but
otherwise more or less include the line verbatim in the CREATE TABLE
block.
GIS guys, any particular reasons for the approach you took? -- laziness?
economy? "it works, dammit!"? technical reason against the above?
Of course, this is all peripheral to the SoC project, because I you
really would need _post_create_sql() to add a constraint to a field if
we didn't want to drastically change the SQL construction. So maybe it's
all moot, since _post_create_sql() is probably providing a super-set of
functionality of a mythical _get_field_sql() anyway.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
