Django orm and no primary key

[Thorsten Sanders]

Hello,

I am wondering if it is possible to still use the django orm without
having a primary key at all, I currently got a table holding 61 million
entries soon gonna expand to hold 600 million entries, that table never
need to identify one entry alone its only to pull off statistics based
on other fields, so far I dropped the primary key index in the database
and all works fine, but I know the orm always want a primary key, would
it still work if I for example claim one of the fields which aren't
unique as the primary key?

Or is the only way to do it, use the cursor or even mysqldb directly?

Greetings,
Thorsten

[webonomic]

The Django Book alludes to this, and maybe the comments there will
help you.

Go to http://www.djangobook.com/en/1.0/chapter05/
and search for this paragraph:

"Finally, note we haven’t explicitly defined a primary key in any of
these models. Unless you instruct it otherwise, Django automatically
gives every model an auto-incrementing integer primary key field
called id. Each Django model is required to have a single-column
primary key."

Jared

[Ian Clelland]

On Tue, Jan 10, 2012 at 9:04 AM, webonomic <webo...@gmail.com> wrote:

The Django Book alludes to this, and maybe the comments there will
help you.

Go to http://www.djangobook.com/en/1.0/chapter05/
and search for this paragraph:

"Finally, note we haven’t explicitly defined a primary key in any of
these models. Unless you instruct it otherwise, Django automatically
gives every model an auto-incrementing integer primary key field
called id. Each Django model is required to have a single-column
primary key."

This is referring to an implicit primary key, which Django will create if you do not specify one. The question was regarding using an existing table with no PK in Django.

> I am wondering if it is possible to still use the django orm without
> having a primary key at all, I currently got a table holding 61 million
> entries soon gonna expand to hold 600 million entries, that table never
> need to identify one entry alone its only to pull off statistics based
> on other fields, so far I  dropped the primary key index in the database
> and all works fine, but I know the orm always want a primary key, would
> it still work if I for example claim one of the fields which aren't
> unique as the primary key?
>
> Or is the only way to do it, use the cursor or even mysqldb directly?

This is possible -- there was some discussion on this list about it just a few days ago. If you tell Django that another field is the actual primary key, then it will not assume that there is an 'id' column (which is good, because otherwise it will try to include that in any SELECT statements that it issues).

As long as you consider this table to be essentially read-only, and you don't try to use the ORM to create any records in it, then you shouldn't have any problems with this. As specific measures:

- Don't try to create records with Model.objects.create() or Model.objects.get_or_create()

- If you have to retrieve records, use filter() rather than get, if you can't ever assume uniqueness

- Similarly, if you have to update records, use update() rather than save().

It sounds like you want to use aggregate queries on this table anyway, so you (hopefully) shouldn't run into any issues.

Oh, and don't register this model with the admin; most of that framework is built around the idea of rows uniquely addressable by their primary key.

--
Regards,
Ian Clelland
<clel...@gmail.com>

[Thorsten Sanders]

Am 10.01.2012 20:46, schrieb Ian Clelland:

This is possible -- there was some discussion on this list about it just a few days ago. If you tell Django that another field is the actual primary key, then it will not assume that there is an 'id' column (which is good, because otherwise it will try to include that in any SELECT statements that it issues).

Seems I should read more often the list, then I wouldnt have missed that one.

As long as you consider this table to be essentially read-only, and you don't try to use the ORM to create any records in it, then you shouldn't have any problems with this. As specific measures:

- Don't try to create records with Model.objects.create() or Model.objects.get_or_create()

- If you have to retrieve records, use filter() rather than get, if you can't ever assume uniqueness

- Similarly, if you have to update records, use update() rather than save().

It sounds like you want to use aggregate queries on this table anyway, so you (hopefully) shouldn't run into any issues.

Yep that fits from the orm side it is only reading to aggregate statistics from a table holding history data, I like the orm style way easier to write/manage than raw queries hence my question, the inserts/deletes are handled lowlevel without django.

And cheers for the answer gave me the motivation to try it out in the near future, currently I only still got that "primary key" to not break the orm, removing it would free up quite some not needed space if it works.

Oh, and don't register this model with the admin; most of that framework is built around the idea of rows uniquely addressable by their primary key.

--
Regards,
Ian Clelland
<clel...@gmail.com>

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