Most of the users are not supposed to use get/put calls generally. Direct mutation is convenient and obvious way. There is not much point in that apis at all.
On Thu, Aug 26, 2010 at 12:47 AM, Luke Lu <[email protected]> wrote: > Well, the put_* api is analogous to the ubiquitous/standard file api > where fputc/fputs] on FILE * is buffered by default until a flush. > Changing the api name breaks existing applications and doesn't seem to > gain anything (except for subjective clarity, for worse for me as it > breaks the get/put symmetry.) > > Improving documentation on various options of Mutator/MutateSpec would > be a more productive effort. IMO. > > On Wed, Aug 25, 2010 at 7:56 AM, Doug Judd <[email protected]> wrote: > > Yes, depending on the type of Mutator defined in the MutateSpec, the data > > won't appear until a subsequent flush happens. Also, if there was some > sort > > of failure (e.g. ROW OVERFLOW), then the client won't get notified of the > > failure. This API is really for situations where data loss can be > > tolerated. > > - Doug > > > > On Wed, Aug 25, 2010 at 7:37 AM, Stanislav Yudin <[email protected]> > wrote: > >> > >> > The shared mutator will buffer the cells and flush them at a later > >> > time. > >> So modified cells are not available right after submit? > >> On Wed, Aug 25, 2010 at 7:09 AM, Doug Judd <[email protected]> wrote: > >>> > >>> I'm considering changing the names of the put_ methods of the Thrift > >>> interface from > >>> put_cell > >>> put_cell_as_array > >>> put_cells > >>> put_cells_as_arrays > >>> to ... > >>> submit_cell > >>> submit_cell_as_array > >>> submit_cells > >>> submit_cells_as_arrays > >>> The reason is that these methods merely add cells to a shared mutator > and > >>> return immediately. The shared mutator will buffer the cells and flush > them > >>> at a later time. The term "put" doesn't adequately convey this fact, > >>> whereas "submit" implies that the cells will be submitted to the system > >>> without waiting for the result. > >>> Any objections? > >>> - Doug > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Hypertable Development" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]<hypertable-dev%[email protected]> > . > >>> For more options, visit this group at > >>> http://groups.google.com/group/hypertable-dev?hl=en. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Hypertable Development" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<hypertable-dev%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/hypertable-dev?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Hypertable Development" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<hypertable-dev%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/hypertable-dev?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Hypertable Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<hypertable-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/hypertable-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.
