lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene versions
Date Mon, 08 Dec 2008 22:49:39 GMT
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) <jira@apache.org>
>>>> 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: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message