Sounds good. Thanks for the advice!
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
Fo
On 30/08/10 15:12, Owen Nelson wrote:
> I just started to wonder if the ORM would, I don't
> know... "freak out" on the off-chance I run a query that returns a set of
> objects with duplicate values on what is supposed to be the pk.
Nah, you just get multiple objects back with the same "pk", map
> With the hack i think you mean, it doesn't matter, just pick one, the
> point of the hack is you just shamelessly lie to the django ORM. So make
> sure to make your model ummanaged and _don't_ try to save.
>
Excellent. Yeah, I'd been planning on overriding save() to make it raise
NotImplemented
On 30/08/10 06:07, onelson wrote:
> I've read that a "hack" around this kind of issue is to use the meta
> unique_together property and almost arbitrarily set primary_key on one
> of the fields. That sounds great, except for the fact that I've got
> no guarantee that any given field will actually
I've got an external (read-only) database that I'd like to hook into
an app I'm working on -- it violates django's pk assumption by using
composite keys.
I'm hoping that, given a couple of assumptions of my own, I can hook
these tables up to the ORM without having the universe implode.
Since the d
5 matches
Mail list logo
