On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote:
> I was thinking beyond just handling Foreign Keys actually when I wrote
> this up. It would allow for a more generic version of a generic
> foreign key.
Generic relations are quite different to foreign keys and the two
shouldn't be merged.
Generic Relations say how to get from an object id and a content type to
a remote object. They aren't a database-layer construct, although a
database constraint to, e.g., the content-type table could be
enforced(but that's not relevant here). ForeignKeys are a representation
of a database constraint, always referring to same remote table. They
are necessarily different concepts and I dont' think attempting to merge
them is going to gain much in clarity. At some point when multi-column
primary keys are supported, we might be able to work out a way for
generic relations to handle them, but I'm not holding my breath about
that and it's certainly a phase 2 or phase 3 thing. The reason it's
almost impossible to support generic relations with arbitrary
multi-column fields because the number of columns is, well, arbitrary
(attempting to jam multiple remote values into one local database column
is a bad idea, too. At some point the hacks mount up beyond the point of
usefulness). That is, one content type requires one value, a different
one requires two and a third content type might require four values to
identify the object. I strongly suspect we'll end up just saying
GenericRelation fields only work for single valued objects ids. Which
isn't at all unreasonable, since Django's generic relation classes
aren't really compulsory for data modelling. Any given situation has a
solution that doesn't involve them.
> Although the more I think about it we'd still want to
> magically handle ForeignKey's so the same problem exists.
There's no magic in programming. :-)
Maybe be you mean transparently. If so, I think this is a requirement,
too, but it's not a problem. We know when the ForeignKey field is
specified which model it refers to, so we can include the correct number
of database columns at table creation time. We have perfect information
when we create the table, which is where this differs from any generic
relations.
> I guess I could write a composite foreign key manager, which could be
> used in both instances. The problem is the API is very confusing at
> the moment, and I haven't been able to work out a good way to handle
> (in the code) mycomposite__exact=1 (single to multiple relation
> lookup). Maybe you could help with this :)
The value on the right hand side can be any sequence or tuple (or even
an object that knows how to return a sequence or tuple). The ORM will
know that the field involved is a multicolumn field and know to expect
multiple values on the RHS to associate with the multiple LHS columns.
It doesn't make sense to say mycomposite__exact=1, since mycomposite
expects multiple values. It's clear what
mycomposite__exact = (1,2)
means, however.
I will finish my work on this when I get a chance and as soon as
possible. I realise you've been waiting for a bit. Haven't had a lot of
time for Django the past few weeks, but I'm getting back on the horse
again now, although there'll be a bit of focus on 1.1 feature triage and
1.0.X for a little bit first.
It doesn't mean that you need to specify the primary key columns on the
ForeignKey field, though. As I pointed out in the original message, you
know which are the primary key columns because they're declared on the
model referred to.
>
> Really, this issue is all thats stopping me from completing the
> composite PKs patch.
You should still have something that's in multiple portions, though.
Relations are kind of a second phase to the rest. So you could open a
ticket with the first part of the patch if you want some early review on
that (although you've missed the 1.1 window now, so it will be
deprioritised a little bit officially, but I'm still interested in
coming to some conclusion on this).
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
