I only meant is from a persistence standpoint - if you need a full
"human enterable" query syntax anyway, why not just use that as the
persistence format.
On Dec 8, 2008, at 4:53 PM, Earwin Burrfoot wrote:
Building your own parser with Antlr is really easy. Using Ragel is
harder, but yields insane parsing performance.
Is there any reason to worry about library-bundled parsers if you're
making something more complex then a college project?
On Tue, Dec 9, 2008 at 01:49, robert engels <[EMAIL PROTECTED]>
wrote:
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]
--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
