lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene versions
Date Mon, 08 Dec 2008 22:40:33 GMT
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.


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) <>
>>> To:
>>> Sent: Monday, 8 December, 2008 19:52:46
>>> Subject: [jira] Commented: (LUCENE-1473) Implement standard  
>>> Serialization across Lucene versions
>>>    [

>>> #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:
>>>>            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
>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message