Yeah, that's the new way of doing things. Also check out with ObjectSelect,
SelectById and SQLSelect query classes:
https://cayenne.apache.org/docs/4.0/upgrade-guide/ar01.html#framework-api
> On Jul 31, 2015, at 9:43 PM, Joe Baldwin wrote:
>
> Oops, I missed this one.
>
> So
>
> orde
Oops, I missed this one.
So
order = new Ordering(Product.NAME_PROPERTY, SortOrder.ASCENDING);
would now be something like:
order = Product.NAME.ascInsensitive();
I think I get it now - that is pretty slick! :)
Joe
> On Jul 31, 2015, at 1:25 PM, Andrus Adamchik wrote:
>
>
Andrus,
OK. Please let me verify my understanding. So for example, if I had created an
expression like:
Expression exp =
ExpressionFactory.matchExp(Product.IS_DISABLED_PROPERTY, false);
exp =
exp.andExp(ExpressionFactory.matchExp(Product.IS_VINTAGE_PROPERTY, false));
the new e
> On Jul 31, 2015, at 7:50 PM, Joe Baldwin wrote:
>
> functional replacement that would also give me access to the String value of
> the property (for display purposes).
Here is an example:
(generated code)
@Deprecated
public static final String TITLE_PROPERTY = "title";
public static
In 4.0 M3, we un-deprecated props in the template, as it was annoying indeed.
Instead we made their generation optional per
https://issues.apache.org/jira/browse/CAY-1991 . So if you have a new app, you
won't get String properties, only Property objects. If you want to try it, you
can get an un
I haven't gotten to the point of converting from 3.x to 4.x, but I'm
surprised to hear that the entity *_PROPERTY fields are deprecated.
These values are generated in the templates, so they're totally under
the developer's control. They're not considered part of the cayenne
core library since you
I hope you enjoyed my technical description in the subject heading. :) But it
is, in fact, accurate.
(Context: I am converting from 3.0 to 4.0):
I have been following Cayenne best practices and have been building queries
(and quite a few of the, I might add) with Cayenne-Entity-Property conven
