model for legacy table without primary key

[Sells, Fred]

I thought I had read somewhere that it was possible to have a model for a legacy table without a primary key as long as the useage was read only and that the method was “filter” and not “get”.  I’ve been searching for quite a while now and all I can find indicates a primary key is mandatory for any model.  I’m using Django 1.3 with MySQL 5.0 but plan to upgrade to MySQL 5.5 if that makes any difference.

 

The table has 4 fields that are unique together: userid, application, role, facility.  I populate the latter 3 by decoding the ldap group.  Unfortunately ldap group names are not defined consistently, so I have to write a special parser for each application (that I support in Django).  This table will be refreshed using MySQLdb from a cron job that queries ldap (i.e. no Django at this phase).  This  process updates a generic access table that is used by all my django apps.

 

I control this table, so I could let Django create an autonumber id as primary key, or I could combine all 4 columns to create a  primary key.  Since I really don’t need or have a good use for a primary key in this table, either technique seems inappropriate.  However if I’m being anal about this whole pk issue and need to just  bite the bullet, so be it.

 

Any sage advice?

 

Fred.

[akaariai]

You could just define some arbitrary column as primary key. Primary
key doesn't play any important part in most select queries. It might
be that some queries would break (like Django trying to group by the
fake PK column when aggregating), but most things should just work.
This is what I have done when using some views which do not have
natural single column primary key. Try and see if this works for your
usage.

- Anssi

On Dec 30, 6:50 pm, "Sells, Fred" <fred.se...@adventistcare.org>
wrote:

[Bill Beal]

But it can't be a primary key if the values are not unique, right?

The four fields are unique together, but not necessarily individually.

Bill Beal

--
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.

[akaariai]

On Dec 30, 7:53 pm, Bill Beal <b.b...@eximflow.com> wrote:
> But it can't be a primary key if the values are not unique, right?
> The four fields are unique together, but not necessarily individually.

It is not a real primary key. The idea is to tell Django it is a
primary key even if it is not. And hope everything works OK (should
work for most SELECT queries).

So, it is just an ugly hack. Do not try this with writing queries,
data corruption is guaranteed :)

- Anssi

[K.C. Smith]

You said the four fields are unique together, but "userid" sounds like
it should also be unique be itself, in which case it could be your PK.

In either case, you are being a bit an4l about something that matters
little. You should probably just create another column for an auto-
incrementing PK.

K.C.

[Sells, Fred]

Thanks, that's the hack I was trying to remember.

- Anssi

--