lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rutherglen" <>
Subject Re: Realtime Search for Social Networks Collaboration
Date Sat, 06 Sep 2008 20:04:01 GMT
Hello Shalin,

When I tried to integrate before it seemed fairly simple.  However the
Ocean core code wasn't quite up to par yet so that needed work.  It
will help to work with SOLR people directly who can figure how they
want to integrate such as yourself.  Right now I'm finishing up the
OceanDatabase portion (sorry for all the Ocean names and things, these
can be changed, doesn't matter, but it should be something we agree
on).  The methods to TransactionSystem are like IndexWriter.  The
update method for OceanDatabase is perform(Action action).  There are
3 actions, Insert, Update, Delete.  To execute queries the whole thing
is abstracted out as a Task.  The method is Object run(Task task).
Where task gets a reference to the TransactionSytem. I implemented a
MultiThreadSearchTask that as the name suggests, executes a query in
multiple threads over the latest Snapshot.  The reason for the Task
abstraction is to give the client complete access to the server via a
potentially dynamically loaded subclass of Task.  OceanDatabase should
be the main class for most uses of the realtime system because it
implements optimistic concurrency.  I prefer the simplicity of the
main entry point into the search server being only two methods, with
the run method offering unlimited functionality without recompiling,
building and deploying the server for each new piece of functionality


On Sat, Sep 6, 2008 at 12:53 PM, Shalin Shekhar Mangar
<> wrote:
> Hi Jason,
> I think this is a misunderstanding. I only want to add these features
> incrementally so that users can use them as soon as possible, rather than
> delay them to a later release by re-architecting (which may take more time
> and shift our focus from our users).
> The features are more important than the code but it will of course help a
> lot too. I think a good starting point for us (Lucene/Solr folks) would be
> to study Ocean's source and any documentation that you can provide so that
> we can also suggest an optimal integration strategy or alternate
> implementation ideas. Until now the bulk of such work has been on your
> shoulders. I appreciate your patience and the amount of work you have put
> in. These features will be a huge value proposition for our users and a
> collaboration will be the good for the community in the long term.
> On Sat, Sep 6, 2008 at 9:11 PM, Jason Rutherglen
> <> wrote:
>> Hi Yonik,
>> I fully agree with "good for projects in the long term".  I just
>> figured it would be best if someone went ahead and built the things
>> and they could be integrated later into other projects, that's why I
>> checked them into Apache as patches.  Sounds like a few folks like
>> Shalin and Noble would like to build a SOLR specific realtime search.
>> I think that's a good idea that I may be able to offer some help on.
>> Realtime is relative anyways, for many projects database like updates
>> are probably not necessary, neither is replication, or perhaps even
>> 100% uptime and scalability.  I just want the features, and if someone
>> would like to work with me to get them into core Lucene and SOLR
>> projects that would be cool.  If not at least the code is out there to
>> get ideas from.  These discussions are a good starting point.
>> Cheers,
>> Jason
>> On Sat, Sep 6, 2008 at 11:21 AM, Yonik Seeley <> wrote:
>> > There's a good percent of the Solr community that is looking to add
>> > everything you are (from a functional point of view).  Some of the
>> > other little things that we haven't considered (like a remote Java
>> > API) sound cool... no reason not to add that also.  We're also
>> > planning on adding alternatives to some of the things you don't
>> > currently like about Solr (HTTP, XML config, etc).
>> >
>> > Apache has always emphasized "community over code"... and it's a large
>> > part of what open source is about here.  It's not always easier and
>> > faster to work in an open community, making compromises and trying to
>> > reach general consensus, but it tends to be good for projects in the
>> > long term.
>> >
>> > -Yonik
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> > For additional commands, e-mail:
>> >
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Regards,
> Shalin Shekhar Mangar.

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

View raw message