On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > No.. This is about table options. All of them! Not only storage engine > choice. All of the table options anyone can imagine.
I still feel like it's way too much of a special case to try to do this; the proposed option of an "anything goes" extra string argument for throwing in a kitchen sink worth of table options feels ugly and hackish, and any other solution would end up being nightmarishly complex. Again, I think it's out of scope to expect an ORM to support every possible table option in every database. > I'm trying to make life easier to all of those people needing to do an ALTER > TABLE like that. This tiny change might just do that. > Is it to simple solution? :) The FAQ item Adrian linked provides a pretty clean way to handle this, though; if you're going to distribute an application which relies heavily on DB-specific options which are unsupported in the ORM, you can drop the SQL to add them into a file, and anyone who installs the application will get them -- Django automatiically executes that "initial data" file when syncdb is installing things. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
