Nedjo Rogers wrote:
1. Write a generic object.inc or object.module. Maybe this has two tables of its own: [...] Every object is now uniquely identified not by a single id but by two: the object id and the object type id. Modules can register their own custom object_types. Possibly other core drupal objects also register: files, roles. This has an implication that may not be your intention. In my experience, compound primary keys can be a real bear for subsequent programmers. It obfuscates the table relationships, and can make a field look like a key when it isn't. Perhaps it would be better to guarantee that every object's id will be unique, regardless of type. Aesthetics aside, this would also leave the door open for node type transformations.
This quibble notwithstanding, it seems an excellent approach.
INSERT INTO {object_type} ( values (1, 'node'), (2, 'user'), (3, 'comment'), (4, 'vocabulary'), (5, 'term') ) 2. Having reworked our existing object handling to extend a base object, we then look one by one at the systems currently specific to nodes and consider attaching them to the base object instead, so that they still apply to nodes but are also applicable to other object types An important point: in the current system, all of these data types can overlap. Users can be nodes using nodeuser; anything can be a vocabulary or a term with the category module. I think this is a good thing, and that the primary reason many people dislike the overlap is that it can't be done very cleanly at present. For this reason, and for the sake of CCK-style type inheritance, I think we need another layer between your 'object' and the entities named 'user', 'comment', 'term', etc. I'll explain in a separate followup. .E.g.: Does this sound right? Doable? For 6.0? I wasn't around for the 5.0 effort. Is it OK that this will pretty much break every existing module? Or, on the other hand, would it be feasible for a legacy-support layer to provide API translation?
-Edgar So, what are the basic