cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Zeigler <robert.zeig...@roxanemy.com>
Subject Re: Chainable SelectQuery
Date Fri, 10 Oct 2014 01:32:22 GMT
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. 

GATAATGCTATTTCTTTAATTTTCGAA

> On Oct 9, 2014, at 2:08 PM, Michael Gentry <mgentry@masslight.net> 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, 2014 at 3:03 PM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> 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 <mgentry@masslight.net> wrote:
>>> 
>>> 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 make setFetchLimit() return 'this' (at least
>>> where it makes sense to preserve existing API):
>>> 
>>> query.setFetchLimit(100).setDistinct(true);
>>> 
>>> You could continue that in the model objects, too:
>>> 
>>> person.setFirstName("John").setLastName("Doe");
>>> 
>>> mrg
>>> 
>>> 
>>>> On Thu, Oct 9, 2014 at 1:31 PM, Andrus Adamchik <andrus@objectstyle.org>
wrote:
>>>> 
>>>>> On Oct 7, 2014, at 9:30 PM, Michael Gentry <mgentry@masslight.net>
wrote:
>>>>> 
>>>>> On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis <ari@maniatis.org>
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 the old methods
and make new fluent ones.
>>>>> 
>>>>> I was looking at the changes and was wondering if we really need to
>>>>> deprecate the old methods.  Can't setFetchLimit() live along with
>>>>> limit()?
>>>> 
>>>> I suspect having both will be rather confusing. Initially I even wanted to
leave SelectQuery alone and implement all the new ideas in a separate query class (ObjectQuery?),
but since we've already made a bunch of changes to SelectQuery in the same direction, I ended
up with a massive change to the existing class.
>>>> 
>>>> Andrus
>> 

Mime
View raw message