Reconcile possible duplicated columns in object and versioned object tables #480
Assignees
Labels
area/rgw-sfs
RGW & SFS related
kind/quality
Quality improvements, Refactoring, Automation via CI, E2E, Integration, CLI or REST API
Milestone
Comments
0xavi0
added
the
kind/quality
|
https://github.com/aquarist-labs/s3gw/pull/497, design review 2023-05-05 concluded that we use the versioned object for metadata. Changes: |
jhmarina
changed the title
This was referenced May 15, 2023
0xavi0
referenced
this issue
in 0xavi0/ceph
May 16, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
11 tasks
0xavi0
referenced
this issue
in 0xavi0/ceph
May 16, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
0xavi0
referenced
this issue
in 0xavi0/ceph
May 16, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
0xavi0
referenced
this issue
in aquarist-labs/ceph
Oct 5, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
0xavi0
referenced
this issue
in 0xavi0/ceph
Oct 5, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
0xavi0
referenced
this issue
in aquarist-labs/ceph
Oct 18, 2023
Changes the db schema following [this ADR](https://github.com/aquarist-labs/s3gw/pull/497). It also deletes repeated fields that we had in objects vs versioned_objects tables. Logic of `sfs` was intentionally not updated in this PR. (For example new field `version_type` is added to the schema, but still not used). Updates in logic, specially in versioning logic, will come in a future PR. New Features: **Sqliteorm type bindings for the following types.** * `uuid_d` * `ceph::real_time` * `rgw::sal::sfs::ObjetState` * `rgw::sal::sfs::VersionType` In general, any enum type that has a `LAST_VALUE` item assigned to the last valid value and that also starts with 0 is eligible to be binded to sqliteorm, as the type binding for enums is generic. For example: you can create an enum like: ```c++ enum class TestEnum { WHATEVER = 0, SOMETHING_ELSE, AND_THIS, LAST_VALUE = AND_THIS }; ``` and use it right away in sqliteorm. **Object has no explicit conversion code** As all the types in the `object` are compatible with `sqliteorm` we don't need extra conversion layer. This is a preview of what we can do with the rest of database objects once `BLOBS` are also type binded in the future. That was not done in this PR to avoid too many changes. Note: The new type `VersionType` was added as a new file `version_type.h` because we are in a re-design process and I wasn't sure if it should be located in any other existing file that might be eligible to be deleted in the near future. Fixes: https://github.com/aquarist-labs/s3gw/issues/480 Signed-off-by: Xavi Garcia <xavi.garcia@suse.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now there are a few columns in
objectsandversioned objectstables insqlitethat are repeated or describe the same thing.We should decide which table holds those columns.
Columns we can discuss about:
The text was updated successfully, but these errors were encountered: