> I'll put it on my todo list; if anyone else wants to give it a sanity
> check, I'd appreciate the extra eyeballs.
Looks pretty sane to me, though I wonder if the deserialisation should
raise an exception if the pk is missing and an incomplete set of
natural key fields is provided? Nice work, tha
Hello,
On Jul 9, 9:13 pm, SmileyChris wrote:
> It seems that my ticket in http://code.djangoproject.com/ticket/13252
> covers this. It's ready for review if anyone wants to give it a
> spin...
That patch indeed matches mine, but yours is of course much further
along.
Javier Guerra Giraldez wrot
On Sat, Jul 10, 2010 at 3:13 AM, SmileyChris wrote:
> On Jul 10, 1:47 am, Stijn Hoop wrote:
>> Hi,
>>
>> I am trying to use the 'natural keys' feature of django to make a sort
>> of "future proof" fixture loading possible.
>> [...]
>> With the patch linked below[1] I have successfully used dumpda
Hi Chris,
you're not 100% correct with this statement:
370 When ``use_natural_keys=True`` is specified, the primary key is
no longer
371 provided in the serialized data of this object since it can be
calculated
372 during deserialization::
since in other old fi
On Jul 10, 1:47 am, Stijn Hoop wrote:
> Hi,
>
> I am trying to use the 'natural keys' feature of django to make a sort
> of "future proof" fixture loading possible.
> [...]
> With the patch linked below[1] I have successfully used dumpdata and
> loaddata for a .json export of my tables. Of course
On Fri, Jul 9, 2010 at 8:47 AM, Stijn Hoop wrote:
> 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
