Hi Andy > > On Mon, Mar 7, 2011 at 11:52 AM, Andrzej Michalec < > andrzej.micha...@gmail.com> wrote: > >> > 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 ? >> ... >> > Are you saying you are ok with reverting the change ? If yes then +1. >> >> Sergey, all I am saying is I need to change the implementation a bit. >> After >> that I will revert/re-enable tests to have everything working as it should >> be. >> >> > Super :-). >
One thing I forgot to mention. SearchCondition lets people register custom visitors and SQLPrinterVisitor is provided OTB. So users do not delegate back to SearchCondition to filter out the beans which do not match. Instead they just use SearchContext/SearchCondition as a tool for converting FIQL expressions into SQL/etc specific expressions. However given that SearchContext/SearchCondition are parameterized by concrete types such as Book, the query 'space' is limited by properties of Book (and possibly, in the future) by properties of its internal beans. Which is probably fine for most applications but to have the FIQL-to-SQL case working without restrictions so that people could just query the arbitrary dbs I'm planning to introduce some map-like class which would be handled by the parser with some exceptions. I'm not going to do it for 2.4.0 but just letting you know - comments are welcome Sergey
