yuqi1129
commented
1 year ago @jerryshao I have thought about this issue for a while, It seems that it's not possible or necessary to separate entity key encoding from backend storage implementation for the following reasons:
- We need to generate auto incremental ID for key encoding. For
metalakeandcatalog, A random UUID is enough, but forschema,table, and other entities, we need to generate an auto incremental ID for each entity. - It's necessary to store id to name mapping for each entity so that we can get the name of an entity by id. But for those names that haven't existed before, we need to generate a new id for them, And the newly generated ID needs to be stored in the storage backend.
- Currently, Entity key encoding depends on the storage backend interface, not a specific storage backend. I think it's OK to keep it this way. But we need to make sure that the storage backend interface is flexible enough to support different storage backends.
What's your opinion on this issue? Please let me know if you have any suggestions.
jerryshao
What would you like to be improved?
Currently, Entity key encoding implementation heavily depends on a specific key-value storage backend. For example.
CustomEntityKeyEncoderrelies onkvbackendto get auto incremental ID, which is not very elegant. The ideal way is that encoding implement only do entity coding and all things related to storage should be left to key-value storage.How should we improve?
No response
Subtask