[DATACMNS-1322] Add support for immutable objects in PersistentPropertyAccessor Created: 17/May/18  Updated: 26/Jul/18  Resolved: 12/Jul/18

Status: Closed
Project: Spring Data Commons
Component/s: Core, Mapping / Conversion
Affects Version/s: None
Fix Version/s: 2.1 RC1 (Lovelace)

Type: New Feature Priority: Major
Reporter: Mark Paluch Assignee: Oliver Drotbohm
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depend
is depended on by DATACASS-573 Add support for immutable objects Closed
is depended on by DATAKV-225 Add support for immutable objects Closed
is depended on by DATAMONGO-1992 Add support for immutable objects Closed
is depended on by DATAREDIS-849 Add support for immutable objects Closed
is depended on by DATAREST-1260 Adapt to changes in PersistentPropert... Closed
is depended on by DATACOUCH-390 Adapt to API changes for immutable en... Closed
is depended on by DATAES-471 Adapt to changes in immutable entitie... Closed
is depended on by DATAGRAPH-1097 Adapt to changes in auditing for immu... Closed
Duplicate
is duplicated by DATACMNS-1239 Investigate potential usage of wither... Resolved
Relate
relates to DATAMONGO-1842 Optimistic locking allows ReactiveMon... Closed
relates to DATAMONGO-2026 Final id field causes UnsupportedOper... Closed
relates to DATACMNS-1381 Support for immutable collection types Open
Last updater: Mark Paluch
Pull Request URL: https://github.com/spring-projects/spring-data-commons/pull/292
Sprint: Lovelace M2 / M3, Lovelace RC1

 Description   

Immutable design of objects is an emerging pattern that is primarily driven from value objects and Kotlin data class perspectives.
Spring Data requires a certain degree of object mutability to assign generated identifiers, version numbers (using optimistic locking), or auditing. This works by accident using reflection to set final fields.
We should investigate on a possibility to leverage wither methods or Kotlin's built-in support to create new object instances that are associated with identifiers and version numbers.

Right now, we already support immutable objects through constructor creation when reading objects.



 Comments   
Comment by Oliver Drotbohm [ 12/Jul/18 ]

This is now basically in place. Most of the downstream modules fully support immutable types now.

However, e.g. the Elasticsearch module can't as its core APIs were not written with immutability in mind and rely on the parameters being passed being mutable. That has been mitigated by treating all properties like mutable and only using the reflection-based PersistentPropertyAccessor implementation. This needs to be addressed in the next generation of Spring Data Elasticsearch (probably Moore).

Generated at Tue Feb 25 18:38:16 UTC 2020 using Jira 7.13.8#713008-sha1:1606a5c1e7006e1ab135aac81f7a9566b2dbc3a6.