lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot" <ear...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-1473) Implement standard Serialization across Lucene versions
Date Mon, 08 Dec 2008 22:53:53 GMT
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
Mime
View raw message