On Dec 8, 5:13 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> fixture)? As always, suggestions are welcome. The suggestion is - template the json - name each record - the PK is the hash of the name - link FKs by name, so they get the same hash That way a reader can see an PK or FK, stick in its hash, and keep going, without the need to read the other table and find the matching FK or PK, respectively. (the way >cough< Rails does it) The problem now, at loaddata time in production, is the hashes still might (one in a million chance) collide with a preexisting PK. And the next problem is the hashes will bump their PK incrementors way up, throwing away whole ranges of valid fictitious IDs, when the next natural record inserts. How about you add a argument to loaddata, such as --gentle, which throws an error (and rolls everything back) if a new PK collides. Then the new feature can wait while programmers fix their (hardcoded) PKs and try again. That argument would also work at test time, because the unit tests are expected to always get all PKs right, so the --gentle would be always turned on, and would be a kind of assertion. -- Phlip http://zeekland.zeroplayer.com/Uncle_Wiggilys_Travels/1 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
