Hi! On 01/16/2008 03:07 PM Frederik Holljen wrote: >>> No, I don't think we can find a way here, either. We would still need to >>> introduce a new definition class to be used alternatively to >>> ezcPersistentObjectProperty (the current defintion class for >>> properties). This would mean checks anywhere such a property is used in >>> a query, which applies to as many places as it does for the ID property.
> A better way is to create a whole new definition class that supports > both the current and the new id's and to have our code support only > that. In the definition loader we detect if there are old style > definitions which we simply convert to new style definitions. This way > we don't make the code more complicated than necessary. I think this would be step for version 2.0 of PersistentObject. Doing this now isn't a good idea, since the conversion will take quite some time on load. Beside that, it requires a completly new design for defintion files as well as a re-implementation of all currently supported features. >>> Therefore I'd suggest to close #8963 as "Won't implement". > Although I think this issue is hard and complicated I think we should > support it eventually since not having this functionality can be a > showstopper for anyone with legacy databases. This is true for composite IDs, yes. We should re-consider this if we really get the requirement to implement it. 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
