incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: Row, Records, Sessions oh my...
Date Thu, 28 Feb 2013 19:06:44 GMT
See below:

On Thu, Feb 28, 2013 at 1:37 PM, Tim Williams <williamstw@gmail.com> wrote:

> With these new services, there's no guarantee with respect to going
> back to pick up documents? In other words, a search returns some
> results and i go to fetch that document - is there a chance the wrong
> doc could be returned?
>

No, that logic of create and releasing session would be done for you on the
server side.


>
> Also, why is the DocumentRecord necessary? Can't we just pluck the id
> on a Document?
>

We could, but i was trying to reuse thrift objects and I don't want an id
on the Document object.  Mainly because Lucene doesn't require such a thing.


>
> Having the scores as an independent list feels weird from a client
> perspective - I guess some awkwardness is a byproduct of thift though?
>

Kinda, I was trying to avoid creating another object to carry the document
and the score together.  But we can do that, I'm not wed to the current
API.  Just trying to create a higher level API for easier use.


>
> I assume the search methods are samples and it actually take a real
> query object with paging, etc.?
>

No I was thinking of it taking a single string so that we could keep it
simple.  But you do point out a need to pass that information into the
search somehow, I would prefer to pass it in via an enhanced query language.


>
> Thanks,
> --tim
>
> On Wed, Feb 27, 2013 at 7:13 PM, Aaron McCurry <amccurry@gmail.com> wrote:
> > There wasn't any comments on the removing of sessions from the 0.2-dev
> code
> > (https://issues.apache.org/jira/browse/BLUR-61) so I thought I would
> start
> > discussion here.  I have given this a bit of thought over the past week
> and
> > I think that we do need sessions for managing index state.  However I
> don't
> > think that the typical client use case should have to deal sessions as
> well
> > as the complexity of the current RPC.
> >
> > So I offer a compromise, or at least a start to it.
> >
> > I have create a branch that has the RPC definitions checked in, but the
> > server side is not implemented.
> >
> > The major change here is the addition of 2 services.
> >
> > service DocumentService {
> >  DocumentResult searchRecords (1:string table, 2:string query)
> >  void updateRecord (1:string table, 2:DocumentRecord record)
> >  void deleteRecord (1:string table, 2:string id)
> > }
> >
> > service DocumentGroupService extends DocumentService {
> >  DocumentGroupResult searchGroups (1:string table, 2:string query)
> >  void updateGroup (1:string table, 2:DocumentGroup group)
> >  void deleteGroup (1:string table, 2:string id)
> > }
> >
> > As you can see the DocumentGroupService extends DocumentService so that
> you
> > can interact with the documents in groups as if they were singletons.
>  This
> > is similar to the old api where we had Rows (DocumentGroup) and Records
> > (DocumentRecord).  I call the DocumentRecord a record because it contains
> > an id as well as a Document (which has no predefined structure).
> >
> > Also the standard Blur service extends the DocumentGroupService so that
> all
> > the low-level calls are still available to clients that want to deal with
> > the details.
> >
> > A sample program (that won't work) for the DocumentService can be found
> > here:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=blob;f=src/blur-testsuite/src/main/java/org/apache/blur/testsuite/SampleSimpleDocument.java;h=42b1b5bafed5d159d1c7c767fd2da9ed6d20a472;hb=0.2-dev-clientrpc
> >
> > Another sample program (that won't work) for the DocumentGroupService can
> > be found here:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=blob;f=src/blur-testsuite/src/main/java/org/apache/blur/testsuite/SampleSimpleDocumentGroup.java;h=cf2cf66f1ea577e346b0d560b8e1f06b32269b0f;hb=0.2-dev-clientrpc
> >
> > Let me know your thoughts.  Thanks!
> >
> > Aaron
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message