On Nov 9, 2006, at 11:26 PM, Dries Buytaert wrote:
Having simple, specialized tables (like the one above) is anything but a bad thing, IMO.
so, everyone who wants to use relationships has to fend for themselves? provide their own DB tables, their own APIs, etc, etc? :( things i want to use relationships for: project world: 1) issue <-> issue (duplicate, depends on, etc) 2) issue <-> user (currently hard-coded as 3 things: "assigned", "participated", "created", but this is inflexible and there's lots of room for improvement). 3) issue <-> cvs commit (currently only 1 way... the commit points to the issue, not the other way) 4) project <-> project (related projects, dependencies, sub-projects, etc) 5) project <-> user (e.g. email notifications of new releases, but lots of potential) other stuff: 4) user <-> nid (that's all the signup.module should be) ... i could go on and on... -1 to me having to implement separate DB tables and APIs for each of these things. that's going to kill progress on any of this (in terms of the time it'll take me to do it), increase code bloat, and encourage incompatible APIs that are harder for other developers to grok, work with, extend, etc. +1 to giving the relationship itself an id that you can associate metadata with (that's what signup.module would be doing). in fact, jeff eaton's proposal to the list seems fairly complete and straight forward. that's how i see it, at least. ;) thanks, -derek