I, apparently, need to learn to actually look at code before opening my mouth. I had never actually used the dumpdata command (I usually just used the database server's dump feature), so I didn't realize that it doesn't actually dump just straight SQL. Of course, had I thought about it (instead of just babbling), I would have realized that would be a very naive way of doing things. I should have known to expect better from Django :-)
So, sorry for wasting your time. I still think having a command-line flag for turning checks off (with nice, big warnings on it) might be a help, but I'll be quiet. And yes, ordering the tables certainly couldn't hurt, and would be quite nice. I would submit a patch, but clearly, I need to actually have a clue as to what I'm taking about first. -Jeff On Jun 21, 10:59 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Sat, Jun 21, 2008 at 10:19 PM, Jeff FW <[EMAIL PROTECTED]> wrote: > > > On Jun 21, 12:46 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > > wrote: > >> AFAICT, that's the same idea suggested on #3615. The discussion on > >> that ticket describes why it's not the final solution. > > > Ah, I didn't see that ticket link there. Good call. Assuming the > > data in a dumpfile is correct (which, of course, I know you can't), it > > is a valid solution. Meaning, maybe it could be a command-line flag > > for the loaddata command. If I *know* my data is valid, (say I just > > dumped it from a working database using foreign keys), then why not > > let me disable the checks when I load in the data? Running the script > > linked in the ticket afterwards would certainly be an improvement, but > > not essential in all cases. > > The problem is that the cost of being wrong is so high. I might be > absolutely sure that I don't have any problems in my data, but I could > be wrong. If I'm right, there's no problem, but if I'm wrong, I can > get the database into an invalid state, and the first time I'll know > about it is when everything goes to hell because I try to follow an > invalid reference. > > > As for ordering the tables in the dumpfile: I agree that it might not > > be a general solution, as couldn't there be cycles in the foreign > > keys? Or is that not allowed? > > Cycles are certainly both possible and allowed. Hence the problems > with finding a general solution based on model ordering. > > > Anyway, it's certainly a better quickfix for AmanKow's situation than > > editing the dumpfile and rearranging the order of tables. > > Completely aside from the 'it might help some MySQL fixture loading" > angle, there's a cosmetic angle - at the moment, fixtures are dumped > in dictionary order - which is to say, no order at all. Sorting > fixture output (both by model, and internally by key) would make the > dumped output much nicer to spelunk through manually. > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
