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:56:16 GMT
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 <rengels@ix.netcom.com>  
> 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) <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
>>
>>
>
>
>
> -- 
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785


---------------------------------------------------------------------
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