-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental: Allow Entity IDs to be string-valued types #21
Labels
bug
Something isn't working
Comments
nvamelichev
added a commit
that referenced
this issue
Feb 6, 2024
...represented as string values in YDB and marshaled using valueOf()/fromString() and toString() methods. To enable this experimental feature, set EntityIdSchema.allowStringValuedTypesAsEntityIds flag to true and then register your ID as a string-valued type using FieldValueType.registerStringValueType().
nvamelichev
added a commit
that referenced
this issue
Feb 8, 2024
...represented as string values in YDB and marshaled using `valueOf()`/`fromString()` and `toString()`` methods. To enable this experimental feature, annotate your ID type with `@StringValueType(entityId=true)`.
nvamelichev
added a commit
that referenced
this issue
Feb 15, 2024
...represented as string values in YDB and marshaled using `valueOf()`/`fromString()` and `toString()`` methods. To enable this experimental feature, annotate your ID type with `@StringValueType(entityId=true)`.
Prototyping in |
nvamelichev
added a commit
that referenced
this issue
Feb 19, 2024
...represented as string values in YDB and marshaled using `valueOf()`/`fromString()` and `toString()`` methods. To enable this experimental feature, annotate your ID type with `@StringValueType(entityId=true)`.
Closed in favor of #24 |
nvamelichev
added a commit
that referenced
this issue
Feb 29, 2024
**This PR brings an experimental feature**, explicitly annotated as `@ExperimentalApi`: Adding arbitrary converters between Java values and DB-compatible "column values", using new `@CustomValueType` annotation either on the type, or inside `@Column` annotation on the entity field. These "custom value types" can even be used inside IDs, if their converters transform field value into a ID-compatible value (a String, a enum, an integer, a timestamp, a boolean value or a byte array). This feature has the potential to replace all ad-hoc "string-value type" functionality in the future.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This almost works already, except when matching entities by ID using in-memory table: this relies on
EntityIdSchema.compare(ID, ID)
which is inconsistent withID.equals()
in case of string-valued types. We should compare IDs as theirtoString()
values and not their components in this case.The text was updated successfully, but these errors were encountered: