loaddata without pk

[Ariel Mauricio Nunez Gomez]

Is it possible to use loaddata without a pk field and let database set the proper value?

Ariel

[Malcolm Tredinnick]

On Sat, 2007-10-20 at 10:15 -0500, Ariel Mauricio Nunez Gomez wrote:
> Is it possible to use loaddata without a pk field and let database set
> the proper value?

No. The difficulty here is that you wouldn't ever be able to have
relations between models, since they refer to each other using the
primary key values (almost always).

Regards,
Malcolm

--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/

[Ariel Mauricio Nunez Gomez]

Thanks Malcolm,

I just use it to load data for a single model that does not have any relation to others.

I generate the data.json with a script but I don't (know)/(want to set) the pk keys in advance.

Should I modify loaddata to look for the last pk at the start and fill the gaps?

Ariel.

[Russell Keith-Magee]

On 10/20/07, Ariel Mauricio Nunez Gomez <ingenie...@gmail.com> wrote:
> Thanks Malcolm,
>
> I just use it to load data for a single model that does not have any
> relation to others.
>
> I generate the data.json with a script but I don't (know)/(want to set) the
> pk keys in advance.
>
> Should I modify loaddata to look for the last pk at the start and fill the
> gaps?

Feel free to make this modification to your own Django install.
However such a change would not be accepted for inclusion in the
Django trunk. Django serialized data _must_ be able to include
references to other instances.

I'm not fundamentally opposed to the idea you are suggesting -
however, any proposal to change the serializers to accomodate loading
data without specifying PK's will need to provide a solution to the
general problem, not just a "it works as long as you don't reference
other instances" solution.

Yours,
Russ Magee %-)

[Ariel Mauricio Nunez Gomez]

Thanks for your comments Russell,

I was refering to my own django install, I agree that it's not by any chance a solution for the general problem.

Do you think it would be adequate to report the issue in trac?

Regards,
Ariel.

[Malcolm Tredinnick]

I think you're misunderstanding. There's no bug or issue here, at least
as far as you've explained it. Django's loaddata simply isn't designed
for data that isn't fully specified, which includes the pk value.
Instead, it's designed to handle the stuff written out by dumpdata.

If you want to load data that has some slightly different format, as
you've indicated, I wouldn't be looking at loaddata at all -- that's too
specialised. I'd be subclassing the appropriate serializer class and
overriding a few of the methods to look up the starting pk value and
fill them in. That requires no changes to core at all and should be
reasonably straightforward: the serializers (including the deserializer
classes, which is what you're talking about here) are state-based
parsing machines. So it's a matter of putting your hooks into the right
states. They're pretty well documented and there are four examples
already (json, yaml, python and xml) to get you started.

It really sounds like subclassing the deserializer for whichever format
you're using would be the "correct" place to solve this.

Regards,
Malcolm

--
If you think nobody cares, try missing a couple of payments.
http://www.pointy-stick.com/blog/

[Ariel Mauricio Nunez Gomez]

>I think you're misunderstanding. There's no bug or issue here, at least
>as far as you've explained it. Django's loaddata simply isn't designed
>for data that isn't fully specified, which includes the pk value.
>Instead, it's designed to handle the stuff written out by dumpdata.

The issue I was describing was the need to load "pk-less" data in bulk(Like getting a csv file into a table). But you're right: it isn't a django core issue.

>It really sounds like subclassing the deserializer for whichever format
>you're using would be the "correct" place to solve this.

I totally forgot about the serializers.
Thanks for your advice,
It's time to start coding my simpleload.py

Regards,
Ariel.