On Mon, Sep 8, 2008 at 1:24 PM, Niklas Uhrberg <[EMAIL PROTECTED]> wrote:
> While I favour the first ( public interface Spouse extends Association > ) I was under the impression that it would lead to undesirable class > casting situations, but this may be misguided on my part. Yeah, IIRC, it was a matter of that we strip a lot of composite structure in the EntityStore interface to provide a very data-oriented, easy to implement interface, without (or so we hope) classloading and instantiation needs. The subtype of an association seemed to destroy the relatively simpleness of the EntityStore interface. But I am not sure whether there is an easy way (which is hard to find) to solve that. > My second concern is this: association classes are not entities (which > we already discussed) and the fact that they get implemented with > entities will confuse and make the domain model blurred. Good observation. This becomes a difficult part to explain; "Yeah you must create it as an Entity, it will be stored in the store as an entity, but it is not..." > What do you think about backward compatibility, I assume that even if > Rickards current implementation gets released, there can be a second, > better but incompatible in the future? Sure. We are even planning an incompatible release 2.0 already, where we are going to liberate ourselves enough to allow us to break all kinds of compatibility. And such alternative would probably not even warrant any backward incompatibility, only that code migrating to the new pattern would need a schema change hook. Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
