On Dec 31, 2009, at 7:13 AM, Aristedes Maniatis wrote:
How does Key relate to Attribute and Relationship? Is it an interface that both implement?
Unrelated at all, except for the matching name. I thought of using Attributes/Relationships for this purpose, but it is not possible to parameterize them as they are abstract metadata. Their "compiled" counterparts (Property/ArcProperty) could've potentially been used as "keys", but those can't be statically bound to Persistent objects in compile time, as they are generated in runtime.
2. New API:Expression clause1 = Artist.NAME.eq("X"); Expression clause2 = Artist.PAINTINGS.dot(Painting.NAME).eq("Y");Would this be more in keeping with existing usage: Artist.PAINTINGS.join(Painting.NAME).match("Y"); and Artist.PAINTINGS.outerJoin(Painting.NAME).match("Y"); to emulate the "|" we have now.
I like "dot" and "eq" because they have fewer letters, making things more tight. (also we used the term "path", not "join", so I guess there's really no precedent here). But good point about outer joins. Will definitely need to address that aspect.
At first glance Artist.PAINTINGS looks like it should be <Collection<Painting>>. But that breaks the type-safeness. We can tell when a key represents a Relationship (<? extends PersistentObject>) rather than an Attribute. But would we ever want to know when it represents a to-many relation rather than a to-one?
I had this question as well when first looking at Wonder. For the expression building stuff seems like it is ok to not make a distinction between to-one and to-many. However if we stumble on the case where we need to, we can simply subclass Key. (similar to Property/ArcProperty).
Expression qualifier = clause1.and(clause2.or(clause3).or(clause4));
I like this one. I guess we'll go with it. Andrus
