Just to absolutely be clear, is this also true for a batch that span multiple rows?
On Sat, Apr 20, 2013 at 2:42 PM, Ted Yu <[email protected]> wrote: > Operations within each batch are atomic. > They would either all succeed or all fail. > > Time stamps would all refer to the latest cell (KeyVal). > > Cheers > > On Apr 20, 2013, at 12:17 AM, Kristoffer Sjögren <[email protected]> wrote: > > > The schema is known beforehand so this is exactly what I need. Great! > > > > One more question. What guarantees does the batch operation have? Are the > > operations contained within each batch atomic? I.e. all mutations will be > > given the same timestamp? If something fails, all operation fail or can > it > > fail partially? > > > > Thanks for your help, much appreciated. > > > > Cheers, > > -Kristoffer > > > > > > On Sat, Apr 20, 2013 at 4:47 AM, Ted Yu <[email protected]> wrote: > > > >> I don't know details about Kristoffer's schema. > >> If all the column qualifiers are known a priori, mutateRow() should > serve > >> his needs. > >> > >> HBase allows arbitrary number of columns in a column family. If the > schema > >> is dynamic, mutateRow() wouldn't suffice. > >> If the column qualifiers are known but the row is very wide (and a few > >> columns are updated per call), performance would degrade. > >> > >> Just some factors to consider. > >> > >> Cheers > >> > >> On Fri, Apr 19, 2013 at 1:41 PM, Mohamed Ibrahim <[email protected] > >>> wrote: > >> > >>> Actually I do see it in the 0.94 JavaDocs ( > >> > http://hbase.apache.org/0.94/apidocs/org/apache/hadoop/hbase/client/HTable.html#mutateRow(org.apache.hadoop.hbase.client.RowMutations) > >>> ), > >>> so may be it was added in 0.94.6 even though the jira says fixed in > 0.95 > >> . > >>> I haven't used it though, but it seems that's what you're looking for. > >>> > >>> Sorry for confusion. > >>> > >>> Mohamed > >>> > >>> > >>> On Fri, Apr 19, 2013 at 4:35 PM, Mohamed Ibrahim < > [email protected] > >>>> wrote: > >>> > >>>> It seems that 0.95 is not released yet, mutateRow won't be a solution > >> for > >>>> now. I saw it in the downloads and I thought it was released. > >>>> > >>>> > >>>> On Fri, Apr 19, 2013 at 4:18 PM, Mohamed Ibrahim < > >> [email protected] > >>>> wrote: > >>>> > >>>>> Just noticed you want to delete as well. I think that's supported > >> since > >>>>> 0.95 in mutateRow ( > >> > http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#mutateRow(org.apache.hadoop.hbase.client.RowMutations) > >> ). > >>>>> You can do multiple puts and deletes and they will be performed > >>> atomically. > >>>>> So you can remove qualifiers and put new ones. > >>>>> > >>>>> Mohamed > >>>>> > >>>>> > >>>>> On Fri, Apr 19, 2013 at 3:44 PM, Kristoffer Sjögren < > [email protected] > >>>> wrote: > >>>>> > >>>>>> What would you suggest? I want the operation to be atomic. > >>>>>> > >>>>>> > >>>>>> On Fri, Apr 19, 2013 at 8:32 PM, Ted Yu <[email protected]> > wrote: > >>>>>> > >>>>>>> What is the maximum number of versions do you allow for the > >>> underlying > >>>>>>> table ? > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> On Fri, Apr 19, 2013 at 10:53 AM, Kristoffer Sjögren < > >>> [email protected] > >>>>>>>> wrote: > >>>>>>> > >>>>>>>> Hi > >>>>>>>> > >>>>>>>> Is it possible to completely overwrite/replace a row in a single > >>>>>> _atomic_ > >>>>>>>> action? Already existing columns and qualifiers should be removed > >>> if > >>>>>> they > >>>>>>>> do not exist in the data inserted into the row. > >>>>>>>> > >>>>>>>> The only way to do this is to first delete the row then insert > >> new > >>>>>> data > >>>>>>> in > >>>>>>>> its place, correct? Or is there an operation to do this? > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> -Kristoffer > >> >
