On 06/04/12 06:34, j4nu5 wrote:
Actually I am not planning to mess with syncdb and other management
commands. I will only refactor django.db.backends creation functions
like sql_create_model etc. to use the new API. Behaviour and functionality
will be the same after refactor, so management commands like syncdb
will not notice a difference.
Alright, that's at least going to leave things in a good working state,
then.
Currently, I can only think of things like the unique index on SQLite and
oddities in MySQL mostly again from South's test suite, I will give another
update before today's deadline.
There's a few other ones that South handles - like booleans in SQLite -
but a look through the codebase would hopefully give you hints to most
of those.
Are you referring to the fake orm? Well if you are satisfied with my above
explanation, there would be no need for it, since we will be using django's
orm.
Well, the "fake ORM" is exactly what you described above - models loaded
and then cleared from the app cache. I'm not saying it's a bad thing -
it beats what South had before (nothing) - but there could be alternatives.
Well you said it yourself above that "the models API in Django is not
designed with models asmoveable, dynamic objects". That is why I used
a column-based approach. The advantage will be felt in live migrations.
As for using Django fields for type information, I frankly cannot think of a
major valid negative point for now, I will revert later today.
If you plan to continue using
Django fields as type information (as South does), what potential issues
do you see there?
The only issue I can think of is the case of custom fields created by the user.
That's one big issue; one of South's biggest issues today is custom
fields, though that's arguably more the serialisation side of them.
Still, I'd at least like to see how you would want something like, say,
GeoDjango to fit in, even though this GSOC wouldn't cover it - it has a
lot of custom creation code, and alteration types that differ from
creation types (much like SERIAL in postgres, which you _will_ have to
address) and room would have to be made for these kinds of problems.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
