Malcolm Tredinnick 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. > [...] Does that apply even to recursive (reflexive) relationships, when the related model must be specified by name rather than by reference? I don't know enough about the internals to be clear on that, but it seems like it could be problematic.
regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
