The problem with that is that in most cases you still need a "string"
based syntax that "people" can enter...
I guess you can always have an "advanced search" page that builds and
submits the XML query behind the scenes.
On Dec 8, 2008, at 4:40 PM, Erik Hatcher wrote:
Well, there's the pretty sophisticated and extensible XML query
parser in contrib. I've still only scratched the surface of it,
but it meets the specs you mentioned.
Erik
On Dec 8, 2008, at 4:51 PM, robert engels wrote:
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]
---------------------------------------------------------------------
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]
