The EDC uses Java's default java.util.UUID.randomUUID() class, which implement UUID v4.
This creates a fully random UUID, which causes indexation issues and slows down inserts.
By switching to UUID v7, a component of that UUID is the current time, which makes indexation more efficient.
This change could benefit all the tables using a UUID and has therefor been applied to the whole codebase.
This will in particular help reduce the database's load when a lot of leases exist.
No incompatibilities are expected.
Either update to a newer version of the EDC where the problem creating too many leases doesn't happen or propose this change to the core EDC.
Imported a security patch from 0.5 into 0.2.1 https://github.com/eclipse-edc/Connector/pull/3719/files
This only changes the log's output, removing potentially sensitive data.
Update to Eclipse EDC 0.5+.
Adds a workaround to preserve the assets' parameterization feature from pre-0.1 releases in a provider push scenario.
Eclipse EDC before version 0.1 used a different communication protocol that was capable of sending the parameterization data to the provider in a provider push scenario.
This is not possible anymore due to the current IDS specification for transfer messages.
This feature is needed by one of our clients.
The only field (as of IDS version 2024-01) that lets us send data in the concerned message is the DataAddress's properties. This is the field, in combination with specific properties, that we use in this workaround to transfer the missing information to the provider.
This extra information is extracted on the provider's side and put back where it used to be, in the properties of the DataFlowRequest.
The workaround happens at this location:
org.eclipse.edc.connector.transfer.dataplane.flow.ProviderPushTransferDataFlowController.createRequest
With this workaround, a parameterized asset can be requested with the following query:
{
"@type": "https://w3id.org/edc/v0.0.1/ns/TransferRequest",
"https://w3id.org/edc/v0.0.1/ns/assetId": "{{ASSET_ID}}",
"https://w3id.org/edc/v0.0.1/ns/contractId": "{{CONTRACT_ID}}",
"https://w3id.org/edc/v0.0.1/ns/connectorAddress": "https://{{PROVIDER_EDC_FQDN}}/api/dsp",
"https://w3id.org/edc/v0.0.1/ns/connectorId": "{{PROVIDER_EDC_PARTICIPANT_ID}}",
"https://w3id.org/edc/v0.0.1/ns/dataDestination": {
"https://w3id.org/edc/v0.0.1/ns/type": "HttpData",
"https://w3id.org/edc/v0.0.1/ns/baseUrl": "{{DATA_SINK_URL}}",
"https://sovity.de/workaround/proxy/param/pathSegments": "{{PARAMETERIZATION_PATH}}",
"https://sovity.de/workaround/proxy/param/method": "{{PARAMETERIZATION_METHOD}}",
"https://sovity.de/workaround/proxy/param/queryParams": "{{PARAMETERIZATION_QUERY}}",
"https://sovity.de/workaround/proxy/param/mediaType": "{{PARAMETERIZATION_CONTENTTYPE}}",
"https://sovity.de/workaround/proxy/param/body": "{{PARAMETERIZATION_BODY}}"
},
"https://w3id.org/edc/v0.0.1/ns/privateProperties": {},
"https://w3id.org/edc/v0.0.1/ns/protocol": "dataspace-protocol-http",
"https://w3id.org/edc/v0.0.1/ns/managedResources": false
}Where the https://sovity.de/workaround/proxy/param/* carry the parameterization data.
There is a ticket open on the IDS side
The goal is to
- have this feature standardized
- have it implemented in core EDC
- use the new core EDC version
This change is targeting the provider push use-case only. The consumer pull use-case is not affected.
The parameterization feature must work between 2 EDCs that use this forked version.
The parameterization must work from an unpatched Consumer EDC, targeting a patched EDC provider, using the request mentioned in the Implementation section.
The parametrization will not work if the provider EDC is not using this patched version.
Expecting no other incompatibilities with core EDC 0.2.1.