-
Notifications
You must be signed in to change notification settings - Fork 266
fix: allowing sorting Contract Definitions by creation date #5020
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
base: main
Are you sure you want to change the base?
fix: allowing sorting Contract Definitions by creation date #5020
Conversation
1ef851a
to
a135a72
Compare
@@ -26,6 +26,7 @@ | |||
public class ContractDefinitionMapping extends TranslationMapping { | |||
public ContractDefinitionMapping(ContractDefinitionStatements statements) { | |||
add("id", statements.getIdColumn()); | |||
add("createdAt", statements.getCreatedAtColumn()); |
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.
there should be a test for this.
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.
Updated/Adde tests regarding ContractDefinition's createdAt, but no UT related with that specific block, since similar mappings do not seem to have them. Would you propose to create a ContractDefinitionMappingTest?
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 tests you provided do not represent the behavior that you described as failing in the attached issue. Please write a test that checks if the result of a contract definition api request is correctly ordered by creation date, when the request has a query spec contains such an ordering criteria.
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.
Added suggested test. Keep in mind that the createdAt
field is not returned, so I enforced the result extraction as a list to keep the order and validate it with the return ids.
…w_sort_contract_definition_with_created_time
.../src/test/java/org/eclipse/edc/test/e2e/managementapi/ContractDefinitionApiEndToEndTest.java
Outdated
Show resolved
Hide resolved
var id1 = UUID.randomUUID().toString(); | ||
var id2 = UUID.randomUUID().toString(); | ||
var id3 = UUID.randomUUID().toString(); | ||
Stream.of(id1, id2, id3).forEach(id -> store.save(createContractDefinition(id).createdAt(System.nanoTime()).build())); |
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.
Please don't do this. Start with a time and then increment using an offset so it is deterministic.
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.
followed suggestion, changed in here.
…w_sort_contract_definition_with_created_time
Stream.of(id1, id2, id3).forEach(id -> store.save(createContractDefinition(id).createdAt(System.nanoTime()).build())); | ||
var createdAtTime = 1000L; | ||
var increment = new AtomicInteger(0); | ||
Stream.of(id1, id2, id3).forEach(id -> store.save(createContractDefinition(id).createdAt(createdAtTime + increment.getAndIncrement()).build())); |
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.
Why not use an AtomicLong and have it as one operation?
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.
You're right, simplified in here.
|
||
var querySpec = QuerySpec.Builder.newInstance().sortField("createdAt"); | ||
|
||
assertThat(getContractDefinitionStore().findAll(querySpec.sortOrder(SortOrder.ASC).build())).isSortedAccordingTo(Comparator.comparing(ContractDefinition::getCreatedAt)); |
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.
Please format this so the method calls appear on subsequent lines - it makes it easier to read
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.
Done in here.
@@ -117,6 +124,45 @@ void queryPolicyDefinitionWithSimplePrivateProperties(ManagementEndToEndTestCont | |||
.body("size()", is(0)); | |||
} | |||
|
|||
@Test | |||
void queryContractDefinitions_sortByCreatedDate(ManagementEndToEndTestContext context, ContractDefinitionStore store) throws JsonProcessingException { |
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.
Why are you doing this in an end-to-end test? This should be verified by individual unit tests and an integration test for Postgres. End-to-end tests should only verify complete codepaths and should not be used to verify individual functionality.
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.
My reasoning is due to the raised issue was not having the ordered response and with this test that can be confirmed, being a PostgresqlIntegrationTest
.
Similar to what found in here for TransferProcess
s.
If the end result was just the existence of a field, it would not make much sense, but having the order on the final response I believe it adds value.
What if I update this test to be queryContractDefinitions_withQuerySpec
since it is broader and is not currently covered?
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 see verifySortingCreatedAt
covers the case for all store implementations. I don't understand the comment:
What if I update this test to be queryContractDefinitions_withQuerySpec since it is broader and is not currently covered?
Is this test intended to verify that ordering is preserved end-to-end, or does it do something else?
…w_sort_contract_definition_with_created_time
@jimmarino could you review it again? I'd be ready to merge this |
@@ -117,6 +124,45 @@ void queryPolicyDefinitionWithSimplePrivateProperties(ManagementEndToEndTestCont | |||
.body("size()", is(0)); | |||
} | |||
|
|||
@Test | |||
void queryContractDefinitions_sortByCreatedDate(ManagementEndToEndTestContext context, ContractDefinitionStore store) throws JsonProcessingException { |
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 see verifySortingCreatedAt
covers the case for all store implementations. I don't understand the comment:
What if I update this test to be queryContractDefinitions_withQuerySpec since it is broader and is not currently covered?
Is this test intended to verify that ordering is preserved end-to-end, or does it do something else?
var createdAtTime = new AtomicLong(1000L); | ||
Stream.of(id1, id2, id3).forEach(id -> store.save(createContractDefinition(id).createdAt(createdAtTime.getAndIncrement()).build())); | ||
|
||
var content = """ |
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.
Why is a JSON string created and parsed into a query object like this. The query object should be created in code directly.
What this PR changes/adds
Include fix to enable retrieving Contract Definitions sorted by their creation date. Simply updated the mapping for this entity.
Why it does that
We should be able to sort Contract Definitions by their creation date, similar to what is seen with other entities (like assets and policies).
Linked Issue(s)
Closes #4921