cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: SeachConditionBuilder for CXF JAX-RS clients
Date Mon, 07 Mar 2011 10:38:06 GMT
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.
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message