incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: Row, Records, Sessions oh my...
Date Thu, 28 Feb 2013 18:37:51 GMT
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?

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

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

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


On Wed, Feb 27, 2013 at 7:13 PM, Aaron McCurry <> wrote:
> There wasn't any comments on the removing of sessions from the 0.2-dev code
> ( 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:
> Another sample program (that won't work) for the DocumentGroupService can
> be found here:
> Let me know your thoughts.  Thanks!
> Aaron

View raw message