On Thu, Dec 10, 2009 at 1:23 AM, Phlip <phlip2...@gmail.com> wrote: > 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
I'm not sure how this helps. We already have a 100% reliable method for generating JSON - it's called SimpleJSON, and it's part of the Python standard library. > - name each record Where exactly does the name come from when data is being dumped programatically? > - the PK is the hash of the name > - link FKs by name, so they get the same hash Ok; using some non-pk value for PK references is certainly one way to handle this. There is an issue around how to resolve a hash into an actual pk value, but that shouldn't be impossible. The big issue is how to format a hash so that it can be differentiated from a primary key value. To shortcut a couple of obvious (but wrong) solutions: * "just use hash values all the time" isn't an acceptable answer, because we have backwards compatibility to consider * "if it's an int, use pk, if it's a string, use hash" doesn't work, because Django allows strings as primary keys. It isn't common, but it is possible. > 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. Hash collisions aren't a huge concern to me. As long as whatever you are hashing has sufficient entropy that collisions on *input* to the hash aren't possible (or especially likely). > 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. There's one other minor flaw in your proposal - the phrase "How about you add...". If this is your itch, either *you* need to scratch it, or *you* find someone else that will. :-) This is a volunteer project, and code gets written by people that want it. It's worth sticking the idea in Trac, but that doesn't mean that the feature will magically get implemented. 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-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.
