Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: domain of mkienenb@gmail.com designates
 209.85.217.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAA-upzoWHaybaYLaGXi6WpBeyb4gsHp7E1Zvssq3ZngksJSC6Q@mail.gmail.com>
References: <4C8D7FB8-12BC-402E-97EE-31F2F02064B3@objectstyle.org>
 <CAOUwSGv0rKJ078tdjP-u8LW3cLXWc=7h0asYSEa7SUmt6Kg1Zg@mail.gmail.com>
 <54346CCB.9030604@maniatis.org>
 <CAA-upzr500Ub_9d69k-0gxX2gO1fn0vHfE1U4j3ghaVVB-2S2Q@mail.gmail.com>
 <B23BF592-FD02-4B57-85A2-17C059DC8C68@objectstyle.org>
 <CAA-upzoNviqEwB4PD4W1ThPW3r1brUy2iqffWfWem44OdKHCrA@mail.gmail.com>
 <66FF37EE-3665-4DD9-821F-91A7349DD0A9@objectstyle.org>
 <CAA-upzoWHaybaYLaGXi6WpBeyb4gsHp7E1Zvssq3ZngksJSC6Q@mail.gmail.com>
From: Mike Kienenberger <mkienenb@gmail.com>
Date: Thu, 9 Oct 2014 15:13:05 -0400
Message-ID: 
 <CAM1yOjZ1rJMoDSNf57daB8rh2MNy5MNF87AcVrp1nc--yPHt=w@mail.gmail.com>
Subject: Re: Chainable SelectQuery
To: dev@cayenne.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wonder if QueryBuilder is a better approach which would preserve
backwards compatibility.

On Thu, Oct 9, 2014 at 3:08 PM, Michael Gentry <mgentry@masslight.net> wrot=
e:
> 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> wro=
te:
>>>>
>>>>> 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 rea=
lly 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 an=
d 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 wante=
d 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
>>>>
>>>
>>