Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.161.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Zwgl92PgLdv1xfhjlE7ZnG85a2jsrMyOfnkGFM7TQ5TDrSOlmH5koLkifUNwXBVKDQ
         fk2Uc1+h9MoHX0iWDmg3euTPuq5qt39X8Q+3JAoKROzukENhKwIsTE05vt7EyZanZgOS
         to4GM7guI/TTqLVRPFu2crexJK3wvnZpnVC0c=
MIME-Version: 1.0
In-Reply-To: <AANLkTin4rKUcSaDhDh=dOTw05TPTzpvQTFjPAqiD4546@mail.gmail.com>
References: <AANLkTi=D2FafqrM+5F3xSR66qWMAqOppd=ZOt+yoV-YN@mail.gmail.com>
	<1296725481546-3369018.post@n5.nabble.com>
	<AANLkTi=XfN0zik+k811AR+AzL-Xp_eK1kSxFyJoKLFCF@mail.gmail.com>
	<1297179182856-3376071.post@n5.nabble.com>
	<AANLkTi=+_jLMDTVprjimPSph5FgaQRR7388TZNBs-=MG@mail.gmail.com>
	<1297195031591-3376520.post@n5.nabble.com>
	<AANLkTimaasFYsFgQ1PM6693PkVSivYpRy=q6oGTwqY=h@mail.gmail.com>
	<1299367309139-3411039.post@n5.nabble.com>
	<AANLkTik2PHXfiEwX0P=tu2MXbbacQhFq5yfpUb7OiyS+@mail.gmail.com>
	<1299447405518-3411767.post@n5.nabble.com>
	<AANLkTin4rKUcSaDhDh=dOTw05TPTzpvQTFjPAqiD4546@mail.gmail.com>
Date: Mon, 7 Mar 2011 10:38:06 +0000
Message-ID: <AANLkTimSZ-hNqA3gjhs10gjXNQjG0nLKoU_hzgk_CEH=@mail.gmail.com>
Subject: Re: SeachConditionBuilder for CXF JAX-RS clients
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Cc: Andrzej Michalec <andrzej.michalec@gmail.com>
Content-Type: multipart/alternative; boundary=00248c176ab458a439049de2173a

--00248c176ab458a439049de2173a
Content-Type: text/plain; charset=ISO-8859-1

Sorry for the possible noise, seems like the message is being rejected if it
contains Nabble links...

On Mon, Mar 7, 2011 at 10:33 AM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:

> Hi Andy
>
> On Sun, Mar 6, 2011 at 9:36 PM, Andrzej Michalec <
> andrzej.michalec@gmail.com> wrote:
>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > I'm concerned about it.
>> > I've seen the relevant JAXRSClientSeverBookTest being disabled and I'm
>> > honestly not sure why
>> > given
>> > _s=id==2
>> >
>>
>> You could use this query on "id==2" and it worked (you have made
>> unit/system
>> tests). The trick is that when one would make up a query with "name==CXF*"
>> only, without id, this certailny fails since id is internally set to zero
>> instead of null
>
>
> If we start enforcing it then I'm concerned it would make the search
> extension limited.
> The match should be attempted at the individual property level only, that
> is in your example, only a 'name' property should be compared, or
> SimpleSearchCondition should only be initialized with a single internal
> condition only.
>
> I'm not sure at all if we can expect 'real' beans containing non-primitive
> properties only and thus we probably can be 'assured' people won't be using
> SearchCondition.findAll/isMet if for that to work they have to change them
> to meet the new restriction...
>
> Actually, I added a test to the JAXRSAtomPushLoggingSpringTest which
> searches the log records using the queries like 'level==INFO,level==WARN'.
> And for that to work I had to make the change to FIQLParser to ensure that
> SimpleSearchCondition was only initialized with the map of properties which
> were specified in the query given that LogRecord has the dozen (or so :-))
> of other properties. Thus I'm not sure why to fail the match if the
> property, even it is primitive, is not even checked ?
>
>
>>  Since unit/system tests accidentally used all primitve type
>> fields in queries (I mean "id") everything worked fine. Now the tests are
>> broken (and disabled) because I added sanity check inside
>> SimpleSearchCondition which denies work it type T contains primitive
>> types.
>> If Book class had "id" type of Integer, instead of int, it would work as a
>> charm. But it makes too mach of a hastle and as I confirmed it is
>> unnecessary constraint I overlooked, so I just need to take care of the
>> code
>> I committed and replace comparison mechanism in SimpleSearchCondition,
>> plus
>> wire it back in FiqlParser.
>>
>> Are you saying you are ok with reverting the change ? If yes then +1.
>
>
>> Sergey, do you plan this featrue part of 2.4 release, right? Just let me
>> know what deadline is to see if I can handle this change on time.
>>
>>
> SearchConditionBuilder will be part of the 2.4 release so it will be a new
> feature, or may be rather the enhancement toward making the search feature
> more complete as it will facilitate using FIQL on the client side...
>
>
>> Regarding user perspective and how SearchConditionBuilder is a factory for
>> builders, maybe in future other than FIQL -- sounds reasonable, will take
>> care of it too.
>>
>> Sound good. I'd be glad if we could hide initial query() and introduce
> some primitive factory mechanism.
> May be we can make SearchConditionBuilder an abstract class ? Have an
> internal FiqlSearchConditionBuilder as the default instance ? And have
> SearchConditionBuilder.instance() and SearchConditionBuilder.instance(String
> language), with the former delegating to the latter as instance("FIQL") ?
>
> thanks, Sergey
>
>
>> cheers,
>> -andy.
>>
>>

--00248c176ab458a439049de2173a--