Hi,

I am trying to use the 'natural keys' feature of django to make a sort
of "future proof" fixture loading possible.

By "future proof" I mean that I want a site administrator to be able
to add new objects to database tables where I will provide initial
data. But I also want to be able to add new data at a later date,
without overwriting the data they added inbetween.

This is rather impossible without natural keys, for I cannot know the
maximum ID of any primary key of tables that they have added data to.
However with natural keys I can do away with recording the numerical
ID of an object so this should be possible.

While implementing this it turned out that ./manage.py dumpdata --
natural is almost exactly what I want, except for the fact that it
still outputs the primary key for my objects. I see no reason for it
to do this since I really do not care about the exact primary keys
anymore.

With the patch linked below[1] I have successfully used dumpdata and
loaddata for a .json export of my tables. Of course I would like to
see something like this accepted, but this is of course a sort of
"feature request". And maybe I'm not considering an application that
people still have to predetermine their auto-generated primary keys,
even while dumping using --natural etc.

So is this way off? Useful? Please let me know :)

Regards,

--Stijn

[1]: I can't seem to attach stuff using the google groups
webinterface, so find it for a limited time here:

http://sandcat.nl/~stijn/tmp/django-naturalkeys-nopk.diff

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to