cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: Chainable SelectQuery
Date Thu, 09 Oct 2014 18:51:55 GMT
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