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 required.
Regards, Jason On Sat, Sep 6, 2008 at 12:53 PM, Shalin Shekhar Mangar <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > -- > Regards, > Shalin Shekhar Mangar. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
