[
https://jira.jboss.org/jira/browse/DNA-467?page=com.atlassian.jira.plugin...
]
Randall Hauch commented on DNA-467:
-----------------------------------
Restructured the SearchEngine functionality to simplify it, and to change over to have
implementations be extensions. To specialize, an implementation now simply subclasses the
SearchEngine, and this is instantiated directly.
The SearchEngine is also now oriented around a RequestProcessor. It's possible to
obtain a RequestProcessor to issue multiple requests within a single connection, and this
will make it significantly easier to reuse within a connector implementation (as well as
within the 'dna-repository' module). Also, the SearchEngine's abstract
RequestProcessor implementation provides default implementations for crawling and indexing
entire subgraphs to generate the required UpdatePropertiesRequest and CreateNodeRequest
stream. Specializations are responsible for fully-implementing the RequestProcessor to
handle all the different kinds of requests, including AccessQueryRequest and
FullTextSearchRequest.
Thus, the LuceneSearchEngine can be instantiated directly, as it is now a subclass of
SearchEngine. It also exists in a new 'extensions/dna-search-lucene' project, and
continues to use the two-index design that was implemented previously. This new
implementation uses a customized RequestProcessor implementation. This also should make
it easier to process Changes via the request processor's methods.
Add search/query support to the graph API
-----------------------------------------
Key: DNA-467
URL:
https://jira.jboss.org/jira/browse/DNA-467
Project: DNA
Issue Type: Feature Request
Components: JCR, Query, Search
Affects Versions: 0.5
Reporter: Randall Hauch
Assignee: Randall Hauch
Priority: Blocker
Fix For: 0.7
The graph system needs to be able to push a search/query down to a connector, and we need
to develop a query model (in the form of concrete classes, probably immutable).
Connectors can optionally support queries, and if they do they will process the query and
return the results.
Particular language bindings would be put on top of this query model. For example, JCR
1.0 defines an XPath language. Support for each language would parse a query in that
language and produce a query model.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira