atom feed7 messages in com.googlegroups.django-developersnatural keys and dumpdata
FromSent OnAttachments
Stijn HoopJul 9, 2010 6:47 am 
Javier Guerra GiraldezJul 9, 2010 7:36 am 
SmileyChrisJul 9, 2010 12:13 pm 
burc...@gmail.comJul 9, 2010 2:02 pm 
Russell Keith-MageeJul 9, 2010 11:34 pm 
Stijn HoopJul 10, 2010 2:41 am 
Simon MeersJul 10, 2010 7:14 am 
Subject:natural keys and dumpdata
From:Stijn Hoop ("st.@sandcat.nl)
Date:Jul 9, 2010 6:47:33 am
List:com.googlegroups.django-developers

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