|Andreas Hartmann||Apr 2, 2008 2:05 am|
|Andreas Hartmann||Apr 4, 2008 7:46 am|
|kanth nalluri||Apr 5, 2008 4:25 am|
|Andreas Hartmann||Apr 6, 2008 2:20 pm|
|Andreas Hartmann||May 13, 2008 8:28 am|
|Thorsten Scherler||Jul 16, 2009 2:52 am|
|Andreas Hartmann||Jul 16, 2009 3:18 am|
|Thorsten Scherler||Jul 16, 2009 3:33 am|
|Subject:||Re: API for document search|
|From:||Andreas Hartmann (andr...@apache.org)|
|Date:||Apr 6, 2008 2:20:34 pm|
kanth nalluri schrieb:
its better to put all search results in a way that allow to perform bulk actions like (delete ....etc)
do you have something particular in mind? Would you mind giving a code example?
BTW, a direct translation from search results to a document collection is a bit complicated, because there might be index entries for which the current session doesn't contain a document.
Andreas Hartmann schrieb:
Hi Lenya users,
I'd like to hear about your opinions regarding the search capabilities Lenya should provide.
I have prepared a first draft for the search API:
Any questions and comments are very welcome. In my sandbox I also have a Lucene-based implementation which I'm testing at the moment.
I have the requirement that it should be possible to issue a search for documents from every Java service. For this purpose, I'd like to introduce a service interface, e.g. DocumentSearcher, with a method that returns a list of hits. But I'm not sure about the method signature yet. IMO it has to be something like
Hits find(Index index, Query query)
Should we abstract away Lucene, or should we just use the Lucene classes Hits and Query? If we introduce our own hits interface, e.g. DocumentHits, it would be easier to obtain the document from a hit:
o.a.l.cms.publication.Document doc = hit.getDocument();
Otherwise, a helper would be needed:
o.a.l.cms.publication.Document doc = searcher.getDocument(hit);
IMO the first version is preferrable.
The same question applies to the Query. That mainly depends on how we want to build queries. If we use the Lucene Query interface, we could
a) use subclasses, e.g. MetaDataQuery (IMO preferrable) b) use helpers, e.g. SearchUtil.buildMetaDataQuery(…)
If we introduce our own Query syntax, things might become more complicated. Another option would be to use just query strings, but this requires us to define a syntax. Or we could just use the Lucene query parser syntax. The signature would then be
Hits find(Index index, String queryString)
BTW, JCR uses the following API:
QueryManager queryManager = workspace.getQueryManager();
Query xPathQuery = queryManager.createQuery("//*", Query.XPATH); Query sqlQuery = queryManager.createQuery("select * …", Query.SQL);
QueryResult result = xPathQuery.execute();
--------------------------------------------------------------------- To unsubscribe, e-mail: user...@lenya.apache.org <mailto:user...@lenya.apache.org> For additional commands, e-mail: user...@lenya.apache.org <mailto:user...@lenya.apache.org>
-- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01