Ya this was more of a two birds one stone goal here. It'd be nice to be able to specify relations (e.g. the filter example), like it would with a generic foreign key, but not restricted to content_type/ object_id. We also will run into the issue with that, where object_id is a composite as well (but this can sit on the backburner IMHO).
Anyways, adding the fields "transparently" (thats what I meant) is easy. I've done it quite a bit in my own code. I spent several hours however, trying to find a way to make ".filter(pk=(1,2,3))", ".filter (pk=dict(blah=1, blah2=2, blah3=3))" work, however. That is the specific area I've been waiting on. I have however had lots of time to find various random admin bugs which I've been slowly fixing up. Filters/etc are all working in my local version. On Nov 13, 10:14 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
