On Jan 29, 2008, at 10:51 PM, Russell Keith-Magee wrote:
> > On Jan 30, 2008 8:17 AM, Joseph Kocherhans <[EMAIL PROTECTED]> > wrote: >> >> I ran into a situation today where for every future site I set up, >> I'll want to load an initial_data fixture, but for some existing >> sites >> that I'm upgrading, it's very useful to be able to run syncdb without >> loading any fixtures. Thus http://code.djangoproject.com/ticket/6511 I'm -0 to the original idea. I would be +1 to the idea if a different management command was created that did only the creation tasks of syncdb, but was called something else (create_missing?). syncdb is named pretty aptly, I think. But I'm -1 to the below: > I imagine the use case here is that the data in the initial data > fixture might be modified after being loaded, in which case you don't > want the modifications being overwritten on each syncdb. IMHO, the > better solution to this problem would be to ensure that initial_data > for a given model is only loaded for models that have been added as a > result of the syncdb (e.g, on first sync, contrib.User is added, so > the initial_data users are added; on the second sync, blog.Entry is > added, so the initial entry is added, but the initial user is not > reloaded). I haven't looked at this in detail, but my gut reaction is > that this wouldn't be a trivial thing to implement. In the meantime, > calling your fixture something else works fine :-) We rely on the syncdb feature that uses initial_data,json to update existing rows. As our developers add columns to models and such, we have to execute ALTER TABLEs by hand when we go from our local development environment to staging, but then we run syncdb and we get all the updated fixtures applied to our updated environment. I think this is not only reasonable but expected behavior, since a broken fixture due to a DB change *must* be updated before your whole app is in a working state. We've already got a great feature in loaddata, let's not waste it. At most, I would recommend that we add a new management command (which is awesome easy now, thanks Django devs)! The command would take in a fixture filename, and then check every app and execute the fixture if it exists in that app. This is very straightforward, it wouldn't interfere with existing functionality, and it should pretty painlessly cover Joseph's original use case needs with maybe only adding a little bit extra from the base fixtures to the external ones. Any reason why a combination of the above wouldn't work to cover everyone's possible use cases, and not break any existing functionality? gav --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
