cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Date Thu, 09 Aug 2012 06:34:43 GMT
Yeah, maintaining multiple versions of the template is somewhat of a pain for us (we need better
tests I guess, otherwise it is very easy to miss when the old template stops working). And
locating the old template and setting up their projects to use it will be a pain for the users.

So while we can provide both versions in 3.2, my vote would be for @Deprecated annotation.


On Aug 9, 2012, at 5:39 AM, Mike Kienenberger wrote:

> cgen used to support a version argument, and we had both a 1.1 and 1.2
> version of templates.   But it's a pain to have to maintain such
> things.
> And is this change really going to change what the generator does?
> Probably not.   It's only going to change the default template.   The
> old template would still work, wouldn't it?
> On Wed, Aug 8, 2012 at 2:52 PM, John Huss <> wrote:
>> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <>wrote:
>>> I am now experimenting with the new class generation too. Since Property
>>> is simply a singleton wrapper of a String name, it is pretty lightweight
>>> IMO.
>>> But now I am wondering whether we still need String constants for property
>>> names? My main use of those was always when building qualifiers. Now this
>>> will be handled via Properties. Besides you can do MY_PROP.getName().
>>> So do we need this extra redundancy in declarations, making the class less
>>> readable? Or should we just keep the Property kind?
>> I would vote for deprecating and then removing the string constants.
>> Have you thought about including multiple revisions of the templates to
>> allow people to stick with older ones if they want to?  Or are they
>> responsible for finding the old file in the source and putting in their app
>> if they don't want to change?
>> John
>> On Aug 3, 2012, at 4:57 AM, Michael Gentry wrote:
>>>> I'm a bit delayed and just saw this ...
>>>> I'm curious how much extra overhead this will add to each Cayenne
>>>> class?  Probably not a huge issue since it is declared statically, but
>>>> I'm still curious.
>>>> Thanks,
>>>> mrg
>>>> On Wed, Jul 11, 2012 at 3:04 AM, Andrus Adamchik <>
>>> wrote:
>>>>> +1. I saw it used on one project and it was a nice concept.
>>>>> Andrus
>>>>> On Jul 11, 2012, at 7:30 AM, John Huss (JIRA) wrote:
>>>>>> John Huss created CAY-1724:
>>>>>> ------------------------------
>>>>>>          Summary: Add 'Property' class for easier and better
>>> Expression creation
>>>>>>              Key: CAY-1724
>>>>>>              URL:
>>>>>>          Project: Cayenne
>>>>>>       Issue Type: Improvement
>>>>>>       Components: Core Library
>>>>>> Affects Versions: 3.2M1
>>>>>>         Reporter: John Huss
>>>>>>         Priority: Minor
>>>>>>      Attachments:
>>>>>> Project Wonder (WebObjects) has a class which is basically just a
>>> wrapper around an attribute or relationship name that gives you a way to
>>> create Expressions in type-safe manner and with minimal effort.  Also sort
>>> orderings can be easily generated.  In Wonder, these "property" objects are
>>> part of the entity template so they are generated automatically.
>>>>>> So for example:
>>>>>> public class _Artist extends CayenneDataObject {
>>>>>> public static final Property<String> NAME = new
>>> Property<String>(NAME_PROPERTY);
>>>>>> ...
>>>>>> }
>>>>>> Then client code can do things like:
>>>>>> new SelectQuery(Artist.class, NAME.eq("Pablo").andExp(,
>>> AGE.descs());
>>>>>> This would select all artists with name equal to Pablo and age greater
>>> than 40 and order them in descending age order.
>>>>>> This concept has been proven to work incredibly well with WebObjects.
>>> It's almost as readable as using plain strings but has complete
>>> compile-time checking for the property name and the type of the objects it
>>> is compared with.
>>>>>> A complete implementation is attached.  It's very simple since
>>> ExpressionFactory does the work.  If this is accepted, it would make sense
>>> to modify the built-in entity templates to generate Property constants for
>>> all of the properties.
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>> administrators:
>>>>>> For more information on JIRA, see:

View raw message