[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Direction of Row Operations (fwd)




> > It was my impression there is consensus to
> > add a getBulkRow type of rowOp, as well as
> > support the capability for rowOps to concurrently
> > retrieve scalars and other random reads.
> > 
> > Of course, we have not been able to gauge
> > consensus on whether the overall approach
> > in the rowOps draft is the correct way to go,
> > or even if the name "rowOps" is appropriate.
> > Time will tell!
> 
> [gww] Good question about consensus. It would be greatly appreciated if
> everyone in favour of the current approach would "hum" by sending an email
> to the EOS list either with approval or with disapproval and improvement
> suggestions.


Since you're asking for comments and opinions here's my two cents worth on
this issue :


   I think there is an obvious need to make row-based operations easier
and more efficient. It's not clear to me whether the row operations should
be implemented through additions to the protocol with new PDUs for each
type of row operation or whether the RowState TC is enough. I do think,
however, that part of making row-based operations easier is making them
more logical. That's part of why I think the concept of an aggregate row
object makes sense. I just sent an e-mail to the EOS mailing list earlier
today with some text outlining an alternative approach to Row Operations
using an aggregate row object as was initially proposed by Dr. Jeff Case
at the 50th IETF conference in Minneapolis.


If we want to be able to perform row-based operations then why not create
a logical representation of rows that represents this? This would allow us
to represent a row (or partial row) as a single unit and perform atomic
operations on an entire row. I think that's close to the functionality 
that Lauren has attempted to provide in the current Row Operations draft,
though her approach doesn't go so far as to define the actual object
type that lets us represent the object as a single aggregate unit. I don't
think the approach using aggregate row objects goes against Lauren's
approach, I think it just takes this a bit further by providing a logical
representation for rows that allows us to represent and operate on
them as we already conceptualize and attempt to operate on them with
the current protocol limitations.

I don't think the definition of new PDUs for each different type of
row operation is necessarily a bad idea, but I'm still not convinced
that this is necessary with an improved RowState Textual Convention
and the use of OID suppression which would allow us to represent
and operate on rows in an efficient and logical manner. 

If it is decided that new PDUs should be defined for each type of
row operation, then I think it is important that these new PDUs
allow for both scalar and row/columnar objects to be operated
on so that you can set scalar locks or retrieve state information
at the same time as you perform row retrieval or configuration 
operations. I also think there is a definite need for more efficient
bulk row/table retrieval so I think if we're going to define new
PDUs for the other type of row operations, then I think the getBulkRow
operation should also be defined.  But, if we are going to allow both
scalar and row/columnar objects to be included in at least some of
these new PDUs, then are they really "Row Operation" PDUs?  I think this
sort of takes us back to the question of whether or not we really need
to define new PDUs for each type of row operation or whether
the RowState TC is going to be sufficient. 


		-sandra