kerneltime commented on PR #6385:
URL: https://github.com/apache/ozone/pull/6385#issuecomment-2010960015

   > The generationID in google cloud appears to be like the version in AWS and 
in Ozone to some extent (I believe versioning is not fully implemented in 
Ozone).
   Versioning != generation ID. Generation is just a monotonically increasing 
number without preserving the older generations.
   > 
   > From the docs:
   > 
   > > There is no guarantee that generation numbers increase for successive 
versions, only that each new version has a unique generation number.
   > > There is no relationship between the generation numbers of unrelated 
objects, even if the objects are in the same bucket.
   > 
   > From that, it is not clear if each generationID is unique across the 
bucket, or if two different keys can have the the same generationID.
   Each object has its own generation field, it is not based on the bucket.
   
   > 
   > In Ozone, if you create a key, with objectID=5, and then create a new key 
of the same name, the objectID, I believe, remains the same, but the update_id 
is incremented.
   > 
   > If you deleted the key (without versioning enabled) and recreated it, the 
object_ID will change.
   > 
   > UpdateID comes from the Ratis Transaction ID (if Ratis is enabled), so it 
is probably unique on its own without the objectID, but I am not sure if that 
can be trusted without Ratis enabled. Also based on comments in 
WithObjectID.java.
   > 
   > Therefore I think that to guarantee an object has not changed, we need 
both object and update ID.
   > 
   > For now, I don't think we should expose any of this via the S3 or Hadoop 
compatible filesystems. We could also tag the new bucket.overwriteKey() as 
experimental for now, giving us scope to remove it or change it later if we 
decide it is not useful. However I still think it could be adapted to a new 
approach easily behind the public interface. Basically, I think the whole Ozone 
version story and version ID along with object and update ID needs to be fully 
worked out before we expose anything more widely that is done in this PR.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to