cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
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.


Andrus


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 <johnthuss@gmail.com> wrote:
>> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <andrus@objectstyle.org>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 <andrus@objectstyle.org>
>>> 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: https://issues.apache.org/jira/browse/CAY-1724
>>>>>>          Project: Cayenne
>>>>>>       Issue Type: Improvement
>>>>>>       Components: Core Library
>>>>>> Affects Versions: 3.2M1
>>>>>>         Reporter: John Huss
>>>>>>         Priority: Minor
>>>>>>      Attachments: Property.java
>>>>>> 
>>>>>> 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.gt(40)),
>>> 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:
>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
> 


Mime
View raw message