I think Benedict was asking if it would be possible to add the capability.
Actually the old product data doesn't have to die, Benedict. Set VERSIONS > 1 in your schema. The old cell version(s) carrying the old label set will still be there, accessible with a Scan that asks for N versions instead of just the latest. You'll get back a Result with up to N cells to iterate over and figure out how to process and display the information. If you only want the latest, use a Get instead. I think it could be possible to introduce a generic facility for handling the case where you have an existing value on the server, that value has tags attached, now a new mutation op has arrived with a tag attached _and_ another op attribute set by the client is asking for any tags on an earlier cell version be brought forward. For each tag type there would be a registered "combiner" that does what makes sense for its particulars. We do this in core for Append and Increment already, but without the notion of combination. This is an off the cuff remark, caveat: I haven't spent time thinking through implications. > On Apr 13, 2016, at 8:58 AM, Ted Yu <yuzhih...@gmail.com> wrote: > > There is currently no API for appending Visibility Labels. > > checkAndPut() only allows you to compare value, not labels. > > On Wed, Apr 13, 2016 at 8:12 AM, <benedict.whittamsm...@thomsonreuters.com> > wrote: > >> We sell data. A product can be defined as a permission to access data (at >> a cell level). Visibility Labels look like a very good candidate for >> implementing this model. >> >> The implementation works well until we create a new product over old data. >> We can set the visibility label for the new product but, whoops, by >> applying it to the relevant cells we've overwritten all the existing labels >> on those cells, destroying the permissioning of our older products. What to >> do? >> >> One answer would be to append the new visibility label to the existing >> label expressions on the cells with an 'OR'. But I'm not sure that's >> possible .. yet? >> >> Thanks, >> >> Ben >> >> ________________________________ >> >> This e-mail is for the sole use of the intended recipient and contains >> information that may be privileged and/or confidential. If you are not an >> intended recipient, please notify the sender by return e-mail and delete >> this e-mail and any attachments. Certain required legal entity disclosures >> can be accessed on our website.< >> http://site.thomsonreuters.com/site/disclosures/> >>
