On Thursday, 5 April 2012 21:25:19 UTC+5:30, Andrew Godwin wrote: > > Just thought I'd chime in now I've had a chance to look over the current > proposal (I looked at the current one you have in the GSOC system): > > - When you describe feeding things in from local_fields, are you > referring to that being the method by which you're planning to implement > things like syncdb? > 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.
> - I'd like to see a bit more detail about how you plan to test the > code - specifically, there are some backend-specific tests you may need, > as well as some detailed introspection in order to make sure things have > applied correctly. > 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. > - Russ is correct about your models approach - as I've said before in > other places, the models API in Django is not designed with models as > moveable, dynamic objects. > I have taken care of clearing the app cache, after migrations. Actually the entire point of using these 'Django code' based tests is that I wanted to doubly ensure that Django will behave the way its supposed to after the migrations. I could have gone with a SQL only approach e.g. 'SELECT table' after calling db.delete_table but using testing using Django code seemed a bit more comprehensive. Now, to mimic migrations, I needed to alter model definitions. The closest way to resemble actual migration scenario seemed to be to change the definitions in models.py itself. File rename/rewrite is ugly and OS dependent thats why I used a 'temporary setting' based approach. I know that messing with app cache looks a bit hackish but I cannot think of anything else for now. South has one approach to these sorts of > tests, but I'd love to see a cleaner suggestion. > 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. > - There's been some discussion on south-users about the benefits of a > column-based alteration API versus a field/model-based alteration API - > why have you picked a column-based one? If you plan to continue using > Django fields as type information (as South does), what potential issues > do you see there? > Well you said it yourself above that "the models API in Django is not designed with models as moveable, 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. > - Some more detail on your background would be nice - what's your > specific experience with the 3 main databases you'll be handling > (postgres, mysql, sqlite)? What was a "high voltage database migration"? > Sure. I will update it. > Sorry for the late feedback, I've been far too busy. > No problem, as long as you reply to this before the deadline :D > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/5eBCoe2syNYJ. 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.
