Skip to content

Version 1.1.0
Compare
Choose a tag to compare
@Whathecode Whathecode released this 14 Oct 15:07
· 97 commits to master since this release
v1.1.0
d28016a
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

The main reason for this release, although it contains various new features, is to be able to handle concurrency issues when an infrastructure using CARP core is set up to allow parallel incoming application service requests.

... infrastructures using CARP core can now verify on repository writes whether the version of the snapshots in the DB match those of the expected fromSnapshotVersion from the [aggregate root (AR)] which is loaded in memory and on which edits were performed. If not, this means a concurrent incoming requests manipulated the same AR, and an exception can be thrown. This exception can be handled uniformly by retrying the whole request.

This requires a database migration!

Subsystem changes

Common

  • isValidMeasurement can now be called on merged DataTypeMetaDataMap, which is useful if you have types defined in addition to CarpDataTypes in your own DataTypeMetaDataMap (#393)
  • Support handling concurrent repository updates. Repository writes can now verify whether the version of the snapshot being written matches that which is present in the DB. If not, this means another request simultaneously modified the same object. We recommend implementing a custom exception for this with an associated retry strategy which tries to replay the full application service request. (#402)
  • New sensor data types:
  • For sensors which can be configured using a sampling interval (IntervalSamplingScheme), support configuring a fixed set of valid options (#407)
  • If device-specific data is needed on sensor data (e.g., calibration data used to derive the reported EDA values), it can now be passed using the sensorSpecificData field (#411)

Studies

  • Fix: ensure that RecruitmentService.inviteNewParticipantGroup does not send out invitations when repository update fails. This supports replaying this request in case of concurrent repository writes, which in this release can now be verified. (#403)

Deployments

  • Fix: failing DeploymentService requests after calling unregisterDevice (#406)
  • Fix: redeploying devices (when unregistering and re-registering them) failed (#413)

Clients

  • When using ClientManager, prevent having to cast to DeploymentStatusAvailable when StudyStatus is Running (#400)

Database migration

A version field was added to Snapshot. This should be set to 0 when migrating the database. The affected snapshots are:

  • StudySnapshot, including the containing protocolSnapshot if the value is non-null.
  • StudyDeploymentSnapshot, including the containing studyProtocolSnapshot.
  • ParticipantGroupSnapshot
  • StudyProtocolSnapshot
  • RecruitmentSnapshot, including the containing studyProtocol if the value is non-null.

Additionally, the StagedParticipantGroup.invitedOn field was removed, and a isDeployed field was added. The isDeployed field should be set to true. Concretely, when using a document store and CARP's JSON serialization, all values of RecruitmentSnapshot.participantGroups need to:

  • remove the invitedOn field
  • add a isDeployed: true field

Multiplatform release accessible through Maven:
https://mvnrepository.com/artifact/dk.cachet.carp

Assets 4
Loading