lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene versions
Date Mon, 08 Dec 2008 21:51:54 GMT
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
>>     [
>> 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: 
>>> 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
>> 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:

View raw message