Skip to content
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

feat: add private properties to contract definition entity #3534

Merged
merged 26 commits into from Oct 25, 2023

Conversation

mohannad-ezzo
Copy link
Contributor

@mohannad-ezzo mohannad-ezzo commented Oct 12, 2023

What this PR changes/adds

Add private properties to contract definition entity. The implementation supports in-memory and postgres as a store.

Why it does that

The private properties are required to provide the owner with the possibility to add extra properties which should not be exposed outside. This requirement was initiated when we want to add administrative properties like (createdBy, createdAt, chnagedBy, chnagedAt). We assume that the private properties can be used to store such a requirement after registering a listener on the contract definition.
More information is in this discussion:
#2592 (reply in thread)

Further notes

List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.

Linked Issue(s)

Closes #3490

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are always happy to welcome new contributors ❤️ To make things easier for everyone, please make sure to follow our contribution guidelines, check if you have already signed the ECA, and relate this pull request to an existing issue or discussion.

@mohannad-ezzo mohannad-ezzo marked this pull request as ready for review October 12, 2023 16:05
property_name VARCHAR(255) NOT NULL,
property_value TEXT NOT NULL,
property_type VARCHAR(255) NOT NULL,
property_is_private BOOLEAN,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed, since contract definitions can only have private properties.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was copied by the sql asset index implementation, but to be fair I'd prefer to follow the transfer process one, where the private properties are serialized into a json field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed the same pattern which is used for Asset. Therefore, I followed this approach. In addition, I intended to add property_is_private as a preparation for adding non-private properties for the contract definition. To be honest, our usecase for contract definition is just to have private properties, but not for non-private properties. So, as requested, the property property_is_private is removed and the corresponding code is adjusted.

@paullatzelsperger
Copy link
Member

paullatzelsperger commented Oct 13, 2023

@mohannad-ezzo two more things:

  • in a PR description, it's fine to reference a discussion, but briefly stating the reason in the desc. is still required so that reviewers don't have to read long threads of discussions.
  • Also in the PR description, pls use closing keywords when linking the issue, so it gets auto-closed when your PR is merged. I have already done that here.

@codecov-commenter
Copy link

codecov-commenter commented Oct 13, 2023

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (cba9558) 72.49% compared to head (ba282ff) 72.32%.
Report is 3 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3534      +/-   ##
==========================================
- Coverage   72.49%   72.32%   -0.17%     
==========================================
  Files         877      880       +3     
  Lines       17474    17729     +255     
  Branches      994     1021      +27     
==========================================
+ Hits        12667    12822     +155     
- Misses       4391     4471      +80     
- Partials      416      436      +20     
Files Coverage Δ
...ractdefinition/ContractDefinitionApiExtension.java 90.00% <100.00%> (+1.11%) ⬆️
...m/JsonObjectFromContractDefinitionTransformer.java 100.00% <100.00%> (ø)
...orm/JsonObjectToContractDefinitionTransformer.java 100.00% <100.00%> (+9.09%) ⬆️
...contractdefinition/SqlContractDefinitionStore.java 89.13% <100.00%> (+2.82%) ⬆️
...actdefinition/schema/BaseSqlDialectStatements.java 96.15% <100.00%> (-3.85%) ⬇️
...efinition/schema/ContractDefinitionStatements.java 100.00% <100.00%> (ø)
...r/contract/spi/types/offer/ContractDefinition.java 65.90% <54.54%> (-2.67%) ⬇️

... and 16 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@ndr-brt ndr-brt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

property_name VARCHAR(255) NOT NULL,
property_value TEXT NOT NULL,
property_type VARCHAR(255) NOT NULL,
property_is_private BOOLEAN,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was copied by the sql asset index implementation, but to be fair I'd prefer to follow the transfer process one, where the private properties are serialized into a json field.

@paullatzelsperger
Copy link
Member

paullatzelsperger commented Oct 16, 2023

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly?
@ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@mohannad-ezzo
Copy link
Contributor Author

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly? @ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

@paullatzelsperger
Copy link
Member

paullatzelsperger commented Oct 16, 2023

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

@mohannad-ezzo Postgres supports JSON operators, and EDC has a way of converting a QuerySpec into such an operator.

@mohannad-ezzo
Copy link
Contributor Author

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

@mohannad-ezzo Postgres supports JSON operators, and EDC has a way of converting a QuerySpec into such an operator.

@paullatzelsperger @ndr-brt ok, I am going to follow the JSON approach of storing the private properties (instead of a having a separate table) and provide you with an update asap.

@ndr-brt
Copy link
Member

ndr-brt commented Oct 20, 2023

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly? @ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

I agree with paul, plus, using the "separate table" approach will lead to issues in trying to query nested properties (see #3424 )

@mohannad-ezzo
Copy link
Contributor Author

mohannad-ezzo commented Oct 24, 2023

As discussed I adapted the PR so that JSON is used to store private properties of contract definition instead of storing them in a separate table.

Copy link
Member

@ndr-brt ndr-brt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just avoid those two not necessary changes to the sql store and it's ready to be merged

@mohannad-ezzo
Copy link
Contributor Author

Just avoid those two not necessary changes to the sql store and it's ready to be merged

Thank you for mentioning this. This actually was inherited from the old logic when I started to have another table for private properties. Old logic is back now :)

@mohannad-ezzo
Copy link
Contributor Author

End-To-End-Tests and Component-Tests failed now. They were ok before the last commit.
Is there any action still required from my side?

@ndr-brt
Copy link
Member

ndr-brt commented Oct 24, 2023

@mohannad-ezzo you need to fix the broken tests and the checkstyle as well

@mohannad-ezzo
Copy link
Contributor Author

@mohannad-ezzo you need to fix the broken tests and the checkstyle as well

I just fixed the checksytle issues. Regarding the broken tests, they ran fine this time without any change from me.
As of now, ALL checks are green and have passed :)

Copy link
Member

@paullatzelsperger paullatzelsperger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@ndr-brt ndr-brt merged commit 059c668 into eclipse-edc:main Oct 25, 2023
17 checks passed
@ndr-brt ndr-brt added the breaking-change Will require manual intervention for version update label Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Will require manual intervention for version update core feature enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adoption Request: Extend Contract Definition entity with Private Properties
4 participants