Doug Cutting wrote:
sergiu gordea wrote:
So .. here is an example of how I parse a simple query string provided by a user ...
the user checks a few flags and writes "test ko AND NOT bo" and the resulting query.toString() is saved in the database:
+(+(subject:test description:test keywordsTerms:test koProperties:test attachmentData:test) +(subject:ko description:ko keywordsTerms:ko koProperties:ko attachmentData:ko) -(subject:bo* description:bo* keywordsTerms:bo* koProperties:bo* attachmentData:bo*)) +creator:2 +classType:package.share.om.knowledgeobject +skillLevel:0 +(keywords:1000 keywords:1020)
I think you agree that is better to be saved in the database instead of creating a
CustomQuery class that implements Serializable and save it in the database.
Your application will be more robust if you instead stored the checked flags and "test ko AND NOT bo" in the database and then re-generate the Lucene query as needed.
For example, if you wanted to add an "author" field that was searched by default, then all of the queries in your database would be invalid. Also, more to the point, if Query.toString() changes, the semantics of your queries might change, or if the QueryParser changes they might even become unparsable.
You are right ... The problem is that the generated String is used in extended search functionality, which is quite often improved. Storing
the "test ko AND NOT bo" string is not enough to regenerate the query, because all the other components of the query depend on user data.
Yes, it is better to store 2 Strings in the database "test ko AND NOT bo" and "+creator:2 +classType:package.share.om.knowledgeobject +skillLevel:0 +(keywords:1000 keywords:1020)"
in the database, and then I'll be able to reconstrunct the query at runtime.
I chose to Store the query.toString() because the parsing of this string required to write just one line of code and it was working perfectly (one line of code means also less maintainance effort).
I'm not a very experenced software developer (I'm still young :)) ), but I've already meet some sitautions when I needed to make reversible some transformations to be reversible
(I mean something like Query => String => Query, with the constraint initial query equals final query).
Ok ... I give up ... if this feature is to hard to be implemented, the soltution will be to work around in my source code to make it work.
The general rule is that the QueryParser should only be used to directly parse user input. Programs should not generate strings to pass to QueryParser. Query.toString() is a program-generated string. If you must save a query, save the user's input.
You are right, but I already explained why it was much more easy to store the generated query String.
And .. there are also some other things to consider. What I explained here is the implementation of the "Saved Search" concept .
The search must return the documents that were found first time + new added documents, even if the structure of the index is changed....
This is my problem, not lucene's, I just wanted to show you how useful is for me the fact that the Query => String transformation is reversible.
Of course there are alternativa solutions all the time.
Best,
Sergiu
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
