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 <[email protected]>wrote: > Hi Andy > > On Sun, Mar 6, 2011 at 9:36 PM, Andrzej Michalec < > [email protected]> 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. >> >>
