On Dec 9, 3:10 pm, Russell Keith-Magee <[email protected]> wrote:
> 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.
In Rails, a YAML (JSON) fixture like this...
norbert:
name: the nark
...expands into this...
norbert:
id: <%= hash('norbert') %>
name: the nark
...hence this:
norbert:
id: 39779393
name: the nark
Then the id stamps into the database as that record's pk.
> 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's why I suggested adding the templating layer to the JSONs.
In general, Django "encourages" screwing with the Admin, then
extruding sample records, while RoR "encourages" writing very terse,
very templated YAML files as test code source.
> > 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).
But abandoning all those fictitious numbers, say between our highest
record of 204 and our hash of 39779393. The auto-incrementor will use
39779394 next, and so on. Then all of those numbers between 204 and
39779393 will feel bad, because they never got to index a record.
> > 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,
I apologize for triggering the "that's how open source works" lecture.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
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.
