You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2012/07/11 09:04:43 UTC
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and better Expression creation
+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 "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
+10.
Most ORMs make it incredibly painful to get at the metadata for a column.
Easily generating queries is just one way to put this to use; another would be updates to the database schema (just use the metadata for old and new schema and glue a bit of transformation code between them); a third would be attaching more metadata such as per-property validation or formatting rules.
SimpleORM might be another source of inspiration.
It's architecturally centered around the metadata, not the Pojos, so it might have details differently in an interesting manner.
> 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.js
> pa 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>.
> embeddable-superclass.vm
> embedable-singleclass.vm
Embeddables (the term is JPA-inspired) is a way to model a bunch of persistent attribute as a single class without its own ID. Then an embeddable can be made an attribute of a regular entity. Eventually we probably want them to have properties too. But I don't see a problem if we omit them initially.
> light-superclass.vm
This was work in progress by Andrey Razumovsky to unify ROP client and regular server persistent objects per https://issues.apache.org/jira/browse/CAY-1230 . This is a worthy goal, but it is unfinished. My suggestion would actually be to remove this template and the corresponding Modeler template choice from trunk and 3.1, to avoid misleading the end users into thinking that this is a working option. Andrey may comment on this further...
For the purpose of CAY-1724 it can certainly be skipped.
Andrus
On Jul 13, 2012, at 7:30 AM, John Huss wrote:
> I think it makes sense add this to these templates:
>
> superclass.vm
> singeclass.vm
> client-superclass.vm
>
> But should the following templates be changed as well? I'm not familiar
> with them.
>
> embeddable-superclass.vm
> embedable-singleclass.vm
> light-superclass.vm
>
> On Thu, Jul 12, 2012 at 8:59 AM, John Huss <jo...@gmail.com> wrote:
>
>> Ok, if you approve I'll commit this class and a change to the entity
>> templates to use it. Then I can do a separate commit to deprecate
>> reflect.Property and create a subclass of it called PropertyDescriptor and
>> then replace all the references to reflect.Property to
>> reflect.PropertyDescriptor.
>>
>>
>> On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
>>
>>> I'd still go with the Property... If we have to I'd rather rename
>>> reflect.Property to something else (PropertyDescriptor?), as it is much
>>> less exposed to the end users, and it would be great to keep simple
>>> expressive names for the "public" side of the API.
>>>
>>> re: package ... org.apache.cayenne.exp looks like a good place for now.
>>> While we are at the very early stages of 3.2, we'll still have the freedom
>>> to move it around later if we decide this wasn't the right place.
>>>
>>> Andrus
>>>
>>>
>>> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
>>>> Yes, it will be confusing. :)
>>>>
>>>> Robert
>>>>
>>>> On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
>>>>
>>>>> Hmm, there is already a Property class in org.apache.cayenne.reflect.
>>>>> Where would this go? Perhaps org.apache.cayenne.exp
>>>>> or org.apache.cayenne.util? Will it be confusing to have two classes
>>> with
>>>>> the same name?
>>>>>
>>>>> John
>>>>>
>>>>> On Wed, Jul 11, 2012 at 2: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 John Huss <jo...@gmail.com>.
I think it makes sense add this to these templates:
superclass.vm
singeclass.vm
client-superclass.vm
But should the following templates be changed as well? I'm not familiar
with them.
embeddable-superclass.vm
embedable-singleclass.vm
light-superclass.vm
On Thu, Jul 12, 2012 at 8:59 AM, John Huss <jo...@gmail.com> wrote:
> Ok, if you approve I'll commit this class and a change to the entity
> templates to use it. Then I can do a separate commit to deprecate
> reflect.Property and create a subclass of it called PropertyDescriptor and
> then replace all the references to reflect.Property to
> reflect.PropertyDescriptor.
>
>
> On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
>
>> I'd still go with the Property... If we have to I'd rather rename
>> reflect.Property to something else (PropertyDescriptor?), as it is much
>> less exposed to the end users, and it would be great to keep simple
>> expressive names for the "public" side of the API.
>>
>> re: package ... org.apache.cayenne.exp looks like a good place for now.
>> While we are at the very early stages of 3.2, we'll still have the freedom
>> to move it around later if we decide this wasn't the right place.
>>
>> Andrus
>>
>>
>> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
>> > Yes, it will be confusing. :)
>> >
>> > Robert
>> >
>> > On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
>> >
>> >> Hmm, there is already a Property class in org.apache.cayenne.reflect.
>> >> Where would this go? Perhaps org.apache.cayenne.exp
>> >> or org.apache.cayenne.util? Will it be confusing to have two classes
>> with
>> >> the same name?
>> >>
>> >> John
>> >>
>> >> On Wed, Jul 11, 2012 at 2: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 Robert Zeigler <ro...@puregumption.com>.
+1
Robert
On Jul 12, 2012, at 7/128:59 AM , John Huss wrote:
> Ok, if you approve I'll commit this class and a change to the entity
> templates to use it. Then I can do a separate commit to deprecate
> reflect.Property and create a subclass of it called PropertyDescriptor and
> then replace all the references to reflect.Property to
> reflect.PropertyDescriptor.
>
> On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
>
>> I'd still go with the Property... If we have to I'd rather rename
>> reflect.Property to something else (PropertyDescriptor?), as it is much
>> less exposed to the end users, and it would be great to keep simple
>> expressive names for the "public" side of the API.
>>
>> re: package ... org.apache.cayenne.exp looks like a good place for now.
>> While we are at the very early stages of 3.2, we'll still have the freedom
>> to move it around later if we decide this wasn't the right place.
>>
>> Andrus
>>
>>
>> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
>>> Yes, it will be confusing. :)
>>>
>>> Robert
>>>
>>> On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
>>>
>>>> Hmm, there is already a Property class in org.apache.cayenne.reflect.
>>>> Where would this go? Perhaps org.apache.cayenne.exp
>>>> or org.apache.cayenne.util? Will it be confusing to have two classes
>> with
>>>> the same name?
>>>>
>>>> John
>>>>
>>>> On Wed, Jul 11, 2012 at 2: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>.
+1
On Jul 12, 2012, at 4:59 PM, John Huss wrote:
> Ok, if you approve I'll commit this class and a change to the entity
> templates to use it. Then I can do a separate commit to deprecate
> reflect.Property and create a subclass of it called PropertyDescriptor and
> then replace all the references to reflect.Property to
> reflect.PropertyDescriptor.
>
> On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
>
>> I'd still go with the Property... If we have to I'd rather rename
>> reflect.Property to something else (PropertyDescriptor?), as it is much
>> less exposed to the end users, and it would be great to keep simple
>> expressive names for the "public" side of the API.
>>
>> re: package ... org.apache.cayenne.exp looks like a good place for now.
>> While we are at the very early stages of 3.2, we'll still have the freedom
>> to move it around later if we decide this wasn't the right place.
>>
>> Andrus
>>
>>
>> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
>>> Yes, it will be confusing. :)
>>>
>>> Robert
>>>
>>> On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
>>>
>>>> Hmm, there is already a Property class in org.apache.cayenne.reflect.
>>>> Where would this go? Perhaps org.apache.cayenne.exp
>>>> or org.apache.cayenne.util? Will it be confusing to have two classes
>> with
>>>> the same name?
>>>>
>>>> John
>>>>
>>>> On Wed, Jul 11, 2012 at 2: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 John Huss <jo...@gmail.com>.
Ok, if you approve I'll commit this class and a change to the entity
templates to use it. Then I can do a separate commit to deprecate
reflect.Property and create a subclass of it called PropertyDescriptor and
then replace all the references to reflect.Property to
reflect.PropertyDescriptor.
On Thu, Jul 12, 2012 at 1:47 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> I'd still go with the Property... If we have to I'd rather rename
> reflect.Property to something else (PropertyDescriptor?), as it is much
> less exposed to the end users, and it would be great to keep simple
> expressive names for the "public" side of the API.
>
> re: package ... org.apache.cayenne.exp looks like a good place for now.
> While we are at the very early stages of 3.2, we'll still have the freedom
> to move it around later if we decide this wasn't the right place.
>
> Andrus
>
>
> On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
> > Yes, it will be confusing. :)
> >
> > Robert
> >
> > On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
> >
> >> Hmm, there is already a Property class in org.apache.cayenne.reflect.
> >> Where would this go? Perhaps org.apache.cayenne.exp
> >> or org.apache.cayenne.util? Will it be confusing to have two classes
> with
> >> the same name?
> >>
> >> John
> >>
> >> On Wed, Jul 11, 2012 at 2: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>.
I'd still go with the Property... If we have to I'd rather rename reflect.Property to something else (PropertyDescriptor?), as it is much less exposed to the end users, and it would be great to keep simple expressive names for the "public" side of the API.
re: package ... org.apache.cayenne.exp looks like a good place for now. While we are at the very early stages of 3.2, we'll still have the freedom to move it around later if we decide this wasn't the right place.
Andrus
On Jul 11, 2012, at 6:08 PM, Robert Zeigler wrote:
> Yes, it will be confusing. :)
>
> Robert
>
> On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
>
>> Hmm, there is already a Property class in org.apache.cayenne.reflect.
>> Where would this go? Perhaps org.apache.cayenne.exp
>> or org.apache.cayenne.util? Will it be confusing to have two classes with
>> the same name?
>>
>> John
>>
>> On Wed, Jul 11, 2012 at 2: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 Robert Zeigler <ro...@roxanemy.com>.
Yes, it will be confusing. :)
Robert
On Jul 11, 2012, at 7/119:24 AM , John Huss wrote:
> Hmm, there is already a Property class in org.apache.cayenne.reflect.
> Where would this go? Perhaps org.apache.cayenne.exp
> or org.apache.cayenne.util? Will it be confusing to have two classes with
> the same name?
>
> John
>
> On Wed, Jul 11, 2012 at 2: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>.
Hmm, there is already a Property class in org.apache.cayenne.reflect.
Where would this go? Perhaps org.apache.cayenne.exp
or org.apache.cayenne.util? Will it be confusing to have two classes with
the same name?
John
On Wed, Jul 11, 2012 at 2: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
>>>
>>>
>>>
>>
>
Re: [jira] [Created] (CAY-1724) Add 'Property' class for easier and
better Expression creation
Posted by Michael Gentry <mg...@masslight.net>.
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
>>
>>
>>
>