Repository navigation
feat(6418): EnhancedDynamoDB#AutoGeneratedUuidExtension with supplier UUID - #6422
marcusvoltolim wants to merge 1 commit into
Conversation
bae19b0 to
34fcc4e
Compare
- Introduced a customizable `uuidSupplier` in `AutoGeneratedUuidExtension` with default `UUID.randomUUID()` functionality. - Added a builder pattern to create extensions with custom suppliers. - Enhanced tests to validate the custom UUID supplier functionality and maintain backward compatibility. - Refactoring all tests and add more scenarios; - Fixing AutoGeneratedUuidExtension`s JavaDoc
34fcc4e to
79c6d17
Compare
alextwoods
left a comment
There was a problem hiding this comment.
This PR needs to be rebased before I can run CI on it, looks like its based on a pretty out of date commit.
| { | ||
| "type": "feature", | ||
| "category": "AWS DynamoDB Enhanced Client", | ||
| "description": "Refactoring `AutoGeneratedUuidExtension` to accepted UUID supplier to make possible using other UUID versions.", |
There was a problem hiding this comment.
The description has some grammer mistakes and describes implementation rather than the customer feature. Maybe something like:
| "description": "Refactoring `AutoGeneratedUuidExtension` to accepted UUID supplier to make possible using other UUID versions.", | |
| "description": "Added AutoGeneratedUuidExtension.builder().uuidSupplier(Supplier<UUID>) so applications can plug in an alternative UUID generator, for example a time-ordered UUIDv7. The default remains UUID.randomUUID()." |
| <type>so</type> | ||
| <scope>test</scope> | ||
| </dependency> | ||
| <dependency> |
There was a problem hiding this comment.
I don't think we should be introducing a new test dependency here - as far as I can tell this is only used in the tests to verify that the uuid prodcued actually came from our supplier. I've left a comment on that test as well, but I think we should provide our own deterministic supplier instead which will strengthen that test and eliminate this dependency.
| * DynamoDbEnhancedClient.builder().extensions(Stream.concat(ExtensionResolver.defaultExtensions().stream(), | ||
| * Stream.of(AutoGeneratedUuidExtension.create())).collect(Collectors.toList())).build(); | ||
| *} | ||
| * {@code DynamoDbEnhancedClient.builder().extensions(Stream.concat(ExtensionResolver.defaultExtensions().stream(), |
There was a problem hiding this comment.
Why did we change these from @snippet to @code? I think @snippet is a pretty common pattern across this code. Was there some documentation rendering issue you were trying to fix?
| * Stream.of(AutoGeneratedUuidExtension.create())).collect(Collectors.toList())).build(); | ||
| *} | ||
| * {@code DynamoDbEnhancedClient.builder().extensions(Stream.concat(ExtensionResolver.defaultExtensions().stream(), | ||
| * Stream.of(AutoGeneratedUuidExtension.create())).collect(Collectors.toList())).build();} |
There was a problem hiding this comment.
I think there may be an unbalanced paren starting in the line above this one: ...extensions(AutoGeneratedUuidExtension.create())).build(); — one ) too many (if I counted right. Might have mis-read).
| * This extension facilitates the automatic generation of a unique UUID (Universally Unique Identifier) for a specified attribute | ||
| * every time a new record is written to the database. The generated UUID is obtained using the | ||
| * {@link java.util.UUID#randomUUID()} method. | ||
| * {@link java.util.UUID#randomUUID()} method by default or a custom UUID supplier instance provided by the user. |
There was a problem hiding this comment.
Lets add a paragraph documenting (with snippet) the new builder().uuidSupplier(...) entry point — it is currently invisible in the class Javadoc.
| } | ||
|
|
||
| /** | ||
| * Sets the UUID supplier instance , else {@link UUID#randomUUID()} is used by default. Every time a new UUID is generated |
There was a problem hiding this comment.
extra space before comma
|
|
||
| /** | ||
| * Sets the UUID supplier instance , else {@link UUID#randomUUID()} is used by default. Every time a new UUID is generated | ||
| * this supplier will be used to get the current UUID. If a custom supplier is not specified, the default randomUUID |
There was a problem hiding this comment.
Doc nit pick: "Current UUID" doesn't really make sense (I assume this wording was copied).
how about something like:
"Sets the supplier used to generate UUID values. Defaults to UUID::randomUUID. Invoked once per auto-generated attribute on every write; must be thread-safe and must not return null."
| import static org.assertj.core.api.Assertions.assertThat; | ||
| import static org.assertj.core.api.Assertions.assertThatExceptionOfType; | ||
| import static org.assertj.core.api.Assertions.assertThatThrownBy; | ||
| import static org.junit.jupiter.api.Assertions.assertEquals; |
There was a problem hiding this comment.
It looks like we're mixing some different assertion libraries - if possible would probably be better to be consistent
| DefaultOperationContext.create(TABLE_NAME, TableMetadata.primaryIndexName()); | ||
|
|
||
| private final AutoGeneratedUuidExtension atomicCounterExtension = AutoGeneratedUuidExtension.create(); | ||
| class AutoGeneratedUuidExtensionTest { |
There was a problem hiding this comment.
Per the AutoGeneratedTimestamp-regression-analysis checklist, a change to an extension must be exercised against all four TableSchema creation methods and on both sync and async tables, plus the shared-client supported/unsupported matrix. This PR covers StaticTableSchema and bean-via-fromClass only. I think the async gap is the one that matters most for this specific change since the extension instance is now stateful (it holds a supplier) and is shared across concurrent async writes, so async is exactly where a non-thread-safe or misbehaving supplier surfaces.
|
|
||
| } | ||
| private void assertUUIDv7(String uuid) { | ||
| assertEquals(7, UUID.fromString(uuid).version()); |
There was a problem hiding this comment.
Mentioned in comments in the pom.xml as well - I don't think this is actually a useful test because this is an indirect proxy for the property under test, which is "the supplier I injected was the one that produced the stored value" (any other incorrect uuid7 supplier that somehow ended up getting used would still pass this test) - We should be able to use a more deterministic custom supplier.
|
@marcusvoltolim let us know if you are still interested in working on this PR. |
|
It looks like this PR has not been active for more than five days. In the absence of more information, we will be closing this PR soon. Please add a comment to prevent automatic closure, or if the PR is already closed please feel free to open a new one. |
|
Feature was released in: #6373 |
Resolves #6418
uuidSupplierinAutoGeneratedUuidExtensionwith defaultUUID.randomUUID()functionality.Motivation and Context
Possibility of working with other versions of UUID such as v7 which is based on TimeStamp, facilitating the ordering of records by UUID.
Modifications
Adding Supplier and Builder in AutoGeneratedUuidExtension
Testing
Tested the 2 scenarios with standard supplier that uses UUID.randomUUID() and the new scenario setting a supplier that generates UUIDv7, validating the UUID version.
Screenshots (if appropriate)
Types of changes
Checklist
mvn installsucceedsscripts/new-changescript and following the instructions. Commit the new file created by the script in.changes/next-releasewith your changes.License