On Tue, Jan 10, 2012 at 9:04 AM, webonomic <webono...@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
<clell...@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-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to