> Yeah, I don't know if changing setXyz to *not* return 'void' would
> break things (like Tapestry). That would be a huge downer.
Just saw something cool at WOWODC. Instead of changing setXyz to return "this",
people would generate a Builder class for each Java class that has fluent
methods for
> On Nov 29, 2014, at 4:09 AM, Aristedes Maniatis wrote:
>
> On 29/11/2014 1:01am, Andrus Adamchik wrote:
>> Just added another flavor of select method - 'selectFirst'. Unlike
>> 'selectOne' intended for queries that expect at most one row back,
>> 'selectFirst' is a quick way to get the top-o
On 29/11/2014 1:01am, Andrus Adamchik wrote:
> Just added another flavor of select method - 'selectFirst'. Unlike
> 'selectOne' intended for queries that expect at most one row back,
> 'selectFirst' is a quick way to get the top-of-the-list object, even if the
> query matched many objects. I.e.
Just added another flavor of select method - 'selectFirst'. Unlike 'selectOne'
intended for queries that expect at most one row back, 'selectFirst' is a quick
way to get the top-of-the-list object, even if the query matched many objects.
I.e. it is equivalent to "limit(1).selectOne(context)".
A
It is kind of hard for us to detect and prevent all possible conflicts in the
*downstream* code like this. Hope this is not something that completely
prevents the use of Cayenne with Scala though.
Andrus
> On Nov 17, 2014, at 7:59 PM, David Feshbach wrote:
>
> One possible reason to avoid "e
One possible reason to avoid "eq" and "ne" is that they are already methods on
Scala's AnyRef. When using Cayenne in Scala, I get errors like this in my IDE:
> org.apache.cayenne.exp.Property[String] and String are unrelated: they will
> most likely never compare equal
On Nov 17, 2014, at 9:09 A
I definitely do not want "is", especially since the the negated operation
has to be consistent - "eq" and "ne" works.
I like "where".
I would stick with "select" since we have SQLSelect and ObjectSelect.
Unless we have good alternatives names for those too.
On Mon, Nov 17, 2014 at 8:42 AM, Andr
Cayenne Property class is using 'eq' for the same reason.
> On Nov 17, 2014, at 5:07 PM, Mike Kienenberger wrote:
>
> Chainable fest testing assertions use "isEqualTo" to avoid confusion
> with "equals"
>
>
> On Mon, Nov 17, 2014 at 9:01 AM, Michael Gentry wrote:
>> On Sun, Nov 16, 2014 at 9
Chainable fest testing assertions use "isEqualTo" to avoid confusion
with "equals"
On Mon, Nov 17, 2014 at 9:01 AM, Michael Gentry wrote:
> On Sun, Nov 16, 2014 at 9:13 AM, Andrus Adamchik
> wrote:
>>> "eq" with "is",
>>
>> I actually prefer "eq[uals]". Considering all other operations in the
On Sun, Nov 16, 2014 at 9:13 AM, Andrus Adamchik wrote:
>> "eq" with "is",
>
> I actually prefer "eq[uals]". Considering all other operations in the
> Property class, "is" creates a bit of asymmetry IMO.
The problem with "equals" is it has other connotations in Java,
otherwise I'd like it just f
On 17/11/2014 5:30pm, Andrus Adamchik wrote:
> What is everyone's thought on "select" -> "find" change?
I think "find" is slightly better than "select". But only slightly. Far more
important is consistency and if we have a dozen other places where we still use
'select' terminology than we should
I am personally of the same opinion re: milestone API evolution.
So we have "exp" -> "where" change, which I'll make. What is everyone's thought
on "select" -> "find" change?
Andrus
> On Nov 17, 2014, at 3:00 AM, Aristedes Maniatis wrote:
>
> On 17/11/2014 1:13am, Andrus Adamchik wrote:
>> I
On 17/11/2014 1:13am, Andrus Adamchik wrote:
> It depends. Most of the new API is very new and can be changed with no
> consequences. Some was already present in 3.2M1 a year ago
> (ObjectContext.select(..), Property). Still can change, but early adopters
> will be affected.
I'm a big +1 on bre
> On Nov 16, 2014, at 4:49 PM, Michael Gentry wrote:
> Perhaps I've missed the boat on this one
It depends. Most of the new API is very new and can be changed with no
consequences. Some was already present in 3.2M1 a year ago
(ObjectContext.select(..), Property). Still can change, but early ad
Hi Andrus,
Perhaps I've missed the boat on this one (been too busy at work, etc),
but I think it might be more readable to not abbreviate names and
perhaps make it read more like a sentence. Given your example,
perhaps something like:
List artists =
ObjectSelect.query(Artist.class)
.where(Ar
> On Oct 11, 2014, at 4:06 AM, Andrus Adamchik wrote:
>
> 1. Instead of drastically redoing good old SelectQuery, we'll create a
> separate class called ObjectSelect featuring fluent API. No deprecations in
> SelectQuery.
> [..]
> Also cases when you need to reset/replace previous settings.
The first step in this direction is committed under CAY-1960. Now you can do
this (with or without a static import) :
import static org.apache.cayenne.exp.ExpressionFactory.*;
and(E1.P1.eq("a"), E1.P2.ge(5), E1.P3.le(77));
or(E1.P1.eq("a"), E1.P2.ge(5));
// new positional binding
exp(
On Oct 11, 2014, at 9:02 AM, Michael Gentry wrote:
> On Fri, Oct 10, 2014 at 9:06 PM, Andrus Adamchik
> wrote:
>> 6. Corollary to #5, we should explore iterator methods in query chains (need
>> to make sure that we don't reinvent the wheels invented in Java 8).
>
> Hi Andrus,
>
> I couldn't
On Fri, Oct 10, 2014 at 9:06 PM, Andrus Adamchik wrote:
> 6. Corollary to #5, we should explore iterator methods in query chains (need
> to make sure that we don't reinvent the wheels invented in Java 8).
Hi Andrus,
I couldn't tell from your #6 if you were saying we should be requiring
Java 8's
I would strongly favor not impacting existing classes, but introduce a new
fluent API or builder patterns.
regards Malcolm
On Sat, Oct 11, 2014 at 12:06 PM, Andrus Adamchik
wrote:
> I think this was a very productive discussion. Based on it and some more
> thinking, here is my takeaway:
>
> 1.
I think this was a very productive discussion. Based on it and some more
thinking, here is my takeaway:
1. Instead of drastically redoing good old SelectQuery, we'll create a separate
class called ObjectSelect featuring fluent API. No deprecations in SelectQuery.
In fact the existing API still
I could go along with calling this 4.0
On Thu, Oct 9, 2014 at 5:15 PM, Michael Gentry
wrote:
> I think you are announcing Cayenne 4.0 ... :-)
>
>
> On Thu, Oct 9, 2014 at 5:37 PM, Andrus Adamchik
> wrote:
> > Based on this discussion I am leaning towards leaving SelectQuery alone
> (perhaps wit
I access my *data* objects all the time in Tapestry templates. Things
such as firstName and lastName. The point I was trying to make is if
setFirstName started returning the 'User' instance instead of 'void',
it could possibly break some libraries out there (such as whatever
Tapestry uses to proc
It would only break tapestry of you were accessing properties of your query
object from your template or via property expressions in bindings. So if your
component had a limit property that was bound to the query's limit, then that
might break.
GATAATGCTATTTCTTTAACGAA
> On Oct 9, 2014, at
I think you are announcing Cayenne 4.0 ... :-)
On Thu, Oct 9, 2014 at 5:37 PM, Andrus Adamchik wrote:
> Based on this discussion I am leaning towards leaving SelectQuery alone
> (perhaps with changes already there, but no fluent builder methods and no
> deprecation), as the impact on everybody
Based on this discussion I am leaning towards leaving SelectQuery alone
(perhaps with changes already there, but no fluent builder methods and no
deprecation), as the impact on everybody will be very big. And creating an
alternative fluent ObjectQuery that will feature all the new stuff.
Andrus
I wonder if QueryBuilder is a better approach which would preserve
backwards compatibility.
On Thu, Oct 9, 2014 at 3:08 PM, Michael Gentry wrote:
> Yeah, I don't know if changing setXyz to *not* return 'void' would
> break things (like Tapestry). That would be a huge downer.
>
> On Thu, Oct 9, 2
Yeah, I don't know if changing setXyz to *not* return 'void' would
break things (like Tapestry). That would be a huge downer.
On Thu, Oct 9, 2014 at 3:03 PM, Andrus Adamchik wrote:
> I thought of that. Unfortunately "setXyz" is a 'java bean' setter, so we'll
> be redefining one of the most esta
I thought of that. Unfortunately "setXyz" is a 'java bean' setter, so we'll be
redefining one of the most established Java conventions.
Andrus
On Oct 9, 2014, at 2:51 PM, Michael Gentry wrote:
> I don't know if it will be confusing or not. At least with the
> current method names, I can type
I don't know if it will be confusing or not. At least with the
current method names, I can type query.set[ctrl+space] and let Eclipse
give me a list of set* method names to choose from (same applies for
get*), but that option won't be available with the new chainable API.
Part of me thinks just ma
On Oct 7, 2014, at 9:30 PM, Michael Gentry wrote:
> On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis wrote:
>>> That said, if returning this is the direction we're going, then really all
>>> the currently void methods in SelectQuery should do the same thing - like
>>> addOrdering for example.
On Oct 7, 2014, at 10/79:31 AM , John Huss wrote:
> Hmm... I have a lot to say, so I might ramble a bit.
>
> 1) Static imports
>
> I'll never been a big user of static imports, largely because the tooling
> (Eclipse) doesn't support them well. Everytime I've used a static import
> (which is r
On Oct 7, 2014, at 7:41 PM, Aristedes Maniatis wrote:
>> Yes both are valid. The point of the new one is that deeply nested
>> expressions can not be easily built within a context of query, so you'd
>> build them separately and then pass the final object to the query. So
>> query.or/and(..) i
On Oct 7, 2014, at 7:41 PM, Aristedes Maniatis wrote:
>>>
>>> Can't we parse without any ambiguity:
>>>
>>> exp("artist.dateOfBirth < $date", c.getTime());
>>
>> In case of a single parameter you are right. Good point!
>
> In the case of multiple parameters could we just as easily pass pa
On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis wrote:
>> That said, if returning this is the direction we're going, then really all
>> the currently void methods in SelectQuery should do the same thing - like
>> addOrdering for example.
>
>
> Correct, but we also need to gracefully deprecate t
On 7/10/2014 10:37pm, Andrus Adamchik wrote:
>> Can't we parse without any ambiguity:
>>
>>exp("artist.dateOfBirth < $date", c.getTime());
>
> In case of a single parameter you are right. Good point!
In the case of multiple parameters could we just as easily pass parameters in
order for a
On 8/10/2014 1:31am, John Huss wrote:
> I'm not a fan of methods that return "this" because it is impossible to
> tell (without looking at javadoc) whether a new instance or the same
> instance is returned.
This pattern was named "fluent" by Martin Fowler.
http://martinfowler.com/bliki/FluentIn
Hmm... I have a lot to say, so I might ramble a bit.
1) Static imports
I'll never been a big user of static imports, largely because the tooling
(Eclipse) doesn't support them well. Everytime I've used a static import
(which is really only in JUnit) I've wanted to import all the members:
import
On Oct 6, 2014, at 8:00 AM, Aristedes Maniatis wrote:
> On 6/10/2014 2:10am, Andrus Adamchik wrote:
>> // a single chain from query to object list
>> List paintings2 = SelectQuery.query(Painting.class,
>> qualifier2).select(context);
>
> Since we already have a constructor with the appropriate
On 6/10/2014 2:10am, Andrus Adamchik wrote:
> // a single chain from query to object list
> List paintings2 = SelectQuery.query(Painting.class,
> qualifier2).select(context);
Since we already have a constructor with the appropriate arguments, why not go
for this as the recommended approach:
40 matches
Mail list logo
