-
-
Notifications
You must be signed in to change notification settings - Fork 1
GSP-111: Add System Metadata In Storage Metadata #111
Conversation
For service metadata, we will introduce `Strong Typed Service Metadata` like `ObjectMetadata`. We will generate following struct for specific service according to service pairs: | ||
|
||
```go | ||
type ServiceMetadata struct { | ||
<service meta> <type> | ||
... | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly?
- In
go-storage/types
, there are typeObject
(has fieldserviceMetadata interface{}
), andStorageMeta
- In
go-service-*
typeObjectMetadata
is used to setserviceMetadata
, and has getterGetObjectMetadata
Now, this proposal intends to also add the field serviceMetadata interface{}
to StorageMeta
. Should the go-service-*
type be called StorageMetadata
?
And I'm wondering why type Object
and StorageMeta
are at the same level 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to rename go-service-*.ObjectMetadata
into something like go-service-*.ServiceObjectMetadata
to avoid confusion? (and correspondingly, ServiceStorageMeta
in this proposal.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The root cause is Object
is a struct but Storager
is an interface.
If Storage
is a struct that exposed to the user, we can set serviceMetadata
in Storage
struct just like we do on Object
.
Well, StorageMeta
and StorageMetadata
do look wired to me too. Do you have a better idea/name for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the most wired one is that both go-storage.Object
and go-storage.StorageMeta
will have field serviceMetadata
,
but go-service-*.ServiceMetadata
will be the one that belongs to StorageMeta
. This seems to be rather confusing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got it.
The problem is introduced by simplify
Service Level/Specified Object Metadata
toserviceMetadata
inObject
Service Level/Specified Storage Metadata
toserviceMetadata
inStorageMeta
But I don't have better ideas about the name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about ServiceObjectMetadata
and ServiceStorageMetadata
?
Naming is so difficult!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can find the opposite word of global
to represent all those situations? So we can:
- Distinguish
Service Pair
andService's Pair
- Distinguish
Service Metadata
andService's Metadata
- ...
And our API will turn into:
func GetObjectXxxxMetadata(o* Object) ObjectXxxxMetadata
func GetStorageXxxxMetadata(s *StorageMeta) StorageXxxxMetadata
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Distinguish
Service Pair
andService's Pair
- Distinguish
Service Metadata
andService's Metadata
Do I understand correctly?
Service Pair
could be all the pairs in the current service.Service's Pair
just means pairs related to the service implementations.Service Metadata
includesobject service metadata
andstorage service metadata
.Service's Metadata
could corresponds toStorageMeta
here.
ping @JinnyYi , Let's use |
fix: #84