You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The above reflects most setups in examples, tutorials and Spring Boot classes are structured but it leaks information about how an entity is stored in a persistence layer into the service layer which is questionable (I know, subjective). In other words, the above approach conflates the definition of domain types (models) with specifying how such a type should be persisted to a specific storage solution, especially since most of the annotations needed are spring-data-mongodb specific.
For developers that prefer to keep the two separated as follows ...
// Domain typeclassSomeEntity {
UUIDid;
...
}
// Persistence schema spec@Document(...)
classSomeDocument {
@IdStringid;
...
}
// NOTE: Here we'd want the MongoRepository to use the model type as 'T' rather than the// document type. Mongo config or some other mechanism should allow us to specify that for actual// persistence `SomeDocument` should be used as the document schema definition and mapping target.interfaceSomeRepositoryextendsMongoRepository<SomeEntity, UUID> {
...
}
...
...there is currently no practical way to use Spring Converter<S, T> or more practical mapping solutions such as mapstruct to automatically map database document object to and from model types (or if there is, it's not obvious how to go about it since none of the callback interfaces such as BeforeConvertCallback and friends allow the work at the right time).
Proposal
Add/allow a mechanism that lets developers configure a mapping/converting interface of some sort such that given M (model type), D (document type), ID (primary id type) a MongoRepository can be defined using <M, ID> whilst some mongo config element allows us to specify that D is the entity that needs to be used by the ORM process and allows specifying a mapper M<->D explicitly, e.g :
I'm sure there's a more elegant solution to it that avoids the somewhat unwieldy unidirectional Converter<S,T> route since you'd always need to support mapping in both directions but whatever the solution looks like I think there should be a way to do this.
If such a mechanism exists I'd much appreciate a pointer in that direction.
The text was updated successfully, but these errors were encountered:
Problem
Currently the typical pattern for
MongoRepository<T, ID>
based interfaces is something likeThe above reflects most setups in examples, tutorials and Spring Boot classes are structured but it leaks information about how an entity is stored in a persistence layer into the service layer which is questionable (I know, subjective). In other words, the above approach conflates the definition of domain types (models) with specifying how such a type should be persisted to a specific storage solution, especially since most of the annotations needed are spring-data-mongodb specific.
For developers that prefer to keep the two separated as follows ...
...there is currently no practical way to use Spring
Converter<S, T>
or more practical mapping solutions such as mapstruct to automatically map database document object to and from model types (or if there is, it's not obvious how to go about it since none of the callback interfaces such asBeforeConvertCallback
and friends allow the work at the right time).Proposal
Add/allow a mechanism that lets developers configure a mapping/converting interface of some sort such that given
M
(model type),D
(document type),ID
(primary id type) aMongoRepository
can be defined using<M, ID>
whilst some mongo config element allows us to specify thatD
is the entity that needs to be used by the ORM process and allows specifying a mapperM
<->D
explicitly, e.g :I'm sure there's a more elegant solution to it that avoids the somewhat unwieldy unidirectional
Converter<S,T>
route since you'd always need to support mapping in both directions but whatever the solution looks like I think there should be a way to do this.If such a mechanism exists I'd much appreciate a pointer in that direction.
The text was updated successfully, but these errors were encountered: