cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Type-safe qualifiers
Date Thu, 31 Dec 2009 08:04:02 GMT

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 ="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  

>  Expression qualifier = clause1.and(clause2.or(clause3).or(clause4));

I like this one. I guess we'll go with it.


View raw message