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
This archive was generated by hypermail 2.0.0 : Thu Dec 31 2009 - 03:04:37 EST