You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <mg...@masslight.net> on 2012/08/03 03:57:20 UTC
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
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 <an...@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
>>
>>
>>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Aug 9, 2012, at 5:11 AM, John Huss wrote:
>>> I would vote for deprecating and then removing the string constants.
>>>
>>
>> A change like this would be a good reason to call the next release 4.0.
>> This would go nicely with creating a completely generified query API. If
>> so, Properties would live only in the new API and String constants in the
>> old. So they would exist side-by-side for a while at least.
>>
>> Or am I overstating the significance of this change?
>
>
> Probably overstating.
Yep, just the Property part prolly does not warrant 4.0 label. When we actually have fully generified API (including select result lists), we might want to think about it again.
Andrus
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by John Huss <jo...@gmail.com>.
On Wed, Aug 8, 2012 at 7:55 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> On 9/08/12 4:52am, John Huss 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.
>>
>
> A change like this would be a good reason to call the next release 4.0.
> This would go nicely with creating a completely generified query API. If
> so, Properties would live only in the new API and String constants in the
> old. So they would exist side-by-side for a while at least.
>
> Or am I overstating the significance of this change?
Probably overstating.
>
>
>
> 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?
>>
>
> Don't most people copy the templates into their own project anyway?
>
I always use a custom template, but from my experience with WO, many people
just use the built-in one.
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 9/08/12 4:52am, John Huss wrote:
> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <an...@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.
A change like this would be a good reason to call the next release 4.0. This would go nicely with creating a completely generified query API. If so, Properties would live only in the new API and String constants in the old. So they would exist side-by-side for a while at least.
Or am I overstating the significance of this change?
> 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?
Don't most people copy the templates into their own project anyway?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by John Huss <jo...@gmail.com>.
Yes, but users would have to obtain the old template to fix the compile
errors in their apps because of the missing string constants. And that may
be fine. But since there is already a drop down box to choose your
template I think it's worth considering providing multiple versions of the
templates especially when there are breaking API changes. But it's not a
big deal either way.
On Wed, Aug 8, 2012 at 9:39 PM, Mike Kienenberger <mk...@gmail.com>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 <jo...@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
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >>
> >>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Aug 9, 2012, at 9:34 AM, Andrus Adamchik wrote:
> So while we can provide both versions in 3.2, my vote would be for @Deprecated annotation.
I just committed this change.
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <jo...@gmail.com> wrote:
>> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <an...@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 <an...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <jo...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <an...@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 <an...@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
>> >>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by John Huss <jo...@gmail.com>.
On Wed, Aug 8, 2012 at 12:34 PM, Andrus Adamchik <an...@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 <an...@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
> >>>
> >>>
> >>>
> >>
> >
>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Posted by Andrus Adamchik <an...@objectstyle.org>.
Or maybe generate those statics with a @Deprecated annotation to assist with migration to 3.2...
On Aug 8, 2012, at 8: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?
>
> Andrus
>
>
>
>
> 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 <an...@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
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
Posted by Andrus Adamchik <an...@objectstyle.org>.
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?
Andrus
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 <an...@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
>>>
>>>
>>>
>>
>