I think an important piece to make this work is the query parser/syntax.
We already have a system similar to what is outlined below. We made
changes to the query syntax to support our various query extensions.
The nice thing, is that persisting queries is a simple string. It
also makes it very easy for external system to submit queries.
We also have XML definitions for a "result set".
I think the only way to make this work though, is probably a more
detailed query syntax (similar to SQL), so that it can be easily
extended with new clauses/functions without breaking existing code.
I would also suggest that any core queries classes have a
representation here.
I would also like to see a way for "proprietary" clauses to be
supported (like calls in SQL).
On Dec 8, 2008, at 3:37 PM, eks dev wrote:
That sounds much better. Trying to distribute lucene (my reason why
all this would be interesting) itself is just not going to work for
far too many applications and will put burden on API extensions.
My point is, I do not want to distribute Lucene Index, I need to
distribute my application that is using Lucene. Think of it like
having distributed Luke, usefull by itself, but not really usefull
for slightly more complex use cases.
My Hit class is specialized Lucene Hit object, my Query has totally
diferent features and agregates Lucene Query... this is what I can
control, what I need to send over the wire and that is the place
where I define what is my Version/API, if lucene API Classes change
and all existing featurs remain, I have no problems in keeping my
serialized objects compatible. So the versioning becomes under my
control, Lucene provides only features, library.
Having light layer, easily extensible, on top of the core API
would be just great, as fas as I am concerned java Serialization is
not my world, having something light and extensible in etch/thrift/
hadop IPC/ProtocolBuffers direction is much more thrilling. That
is exactly the road hadoop, nutch, katta and probably many others
are taking, having comon base that supports such cases is maybe
good idea, why not making RemoteSearchable using hadoop IPC, or
etch/thrift ...
Maybe there are other reasons to suport java serialization, I do
not know. Just painting one view on this idea
----- Original Message ----
From: Doug Cutting (JIRA) <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Monday, 8 December, 2008 19:52:46
Subject: [jira] Commented: (LUCENE-1473) Implement standard
Serialization across Lucene versions
[
https://issues.apache.org/jira/browse/LUCENE-1473?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12654513#action_12654513
]
Doug Cutting commented on LUCENE-1473:
--------------------------------------
Would it take any more lines of code to remove Serializeable from
the core
classes and re-implement RemoteSearchable in a separate layer on
top of the core
APIs? That layer could be a contrib module and could get all the
externalizeable love it needs. It could support a specific
popular subset of
query and filter classes, rather than arbitrary Query
implementations. It would
be extensible, so that if folks wanted to support new kinds of
queries, they
easily could. This other approach seems like a slippery slope,
complicating
already complex code with new concerns. It would be better to
encapsulate these
concerns in a layer atop APIs whose back-compatibility we already
make promises
about, no?
Implement standard Serialization across Lucene versions
-------------------------------------------------------
Key: LUCENE-1473
URL: https://issues.apache.org/jira/browse/
LUCENE-1473
Project: Lucene - Java
Issue Type: Bug
Components: Search
Affects Versions: 2.4
Reporter: Jason Rutherglen
Priority: Minor
Attachments: custom-externalizable-reader.patch,
LUCENE-1473.patch,
LUCENE-1473.patch, LUCENE-1473.patch, LUCENE-1473.patch
Original Estimate: 8h
Remaining Estimate: 8h
To maintain serialization compatibility between Lucene versions,
serialVersionUID needs to be added to classes that implement
java.io.Serializable. java.io.Externalizable may be implemented
in classes for
faster performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
