Hi fellow ezc'ers! During the last eZ conference we discussed the issue of supporting "composite IDs" in the PersistentObject component. So far we only support keys that consist of a single column. The idea behind the issue is to support keys that consist of several columns in addition.
While re-thinking this issue, I wonder how sensible it really is to support this feature and how many people will need and use it, because there is a quite high impact related to the implementation (as Fred, who was originally responsible for it, already noted): To realize composite IDs (and composite properties in general) we need to add a new ID definition class. In every place where we access the ID property of a persiste object we need to branch and check which type of ID is used (there are many places where we access it). Adding those branches makes the code even more unmaintainable as it is now. In addition, handling of composite IDs is much more complex than for single column IDs and will consume more time. Composite IDs are also considered somewhat ugly in terms of database design. They can be easily removed by adding a new key column (single column key) and adding a unique constraint to the original key column. So there is only a real need for them if you need to access already running databases using PersistentObject and cannot influence/change the database design. Another thing are composite properties (except for IDs). While those also mean many code changes and add complexity, I see those more resonable and less complex to implement than composite IDs: They don't affect relation handling and deleting, but only loading and saving of objects. After summarizing my views, the questions now are: 1. Do we need to support composite IDs? 2. Do we want to support composite properties? A draft design (written by Fred) for composite IDs can be found in trunk/PersistentObject/design/design-1.4.txt. Thanks for every feedback! Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
