Retrieve the data before any reactive lambda.
When the method returns, in can immediately be removed from
the currentInvocation, and the previous data restored.
Closes#1392.
Motivation:
Currently an abstract entity class specified in the repository definition can
be used for the predicate typeKey = typeAlias(of abstract entity class) in
queries. Since documents are stored with typeKey = typeAlias(of concrete class)
those queries will never match any documents. To allow this to work,
all of the abstract entity class an all concrete subclasses must use the
same typeAlias.
Once those documents are found, regardless of their concrete class,
they will all have the same typeKey = typeAlias, instead of having the
typeAlias specific to the concrete class. Additional information in
the stored document is needed to identify the concrete class (subtype
in the example test case), as well as a TypeMapper to interpret that
information.
Changes:
This allows a common TypeAlias to be used for the purpose of the predicate
typeKey = typeAlias, and the determination of the concrete type by
implementing an AbstractingMappingCouchbaseConverter that inspects the
'subtype' property.
Closes#1365.
Co-authored-by: Michael Reiche <michael.reiche@couchbase.com>
Translate CasMismatchException to OptimisticLockingFailureException
instead of DataIntegrityViolationException. CasMismatchException is
a ConcurrencyFailureException which is a TransientDataAccessException.
Versus DataIntegrityViolation, which is a NonTransientDataAccessException.
Closed#1339.
The scope for the entity can come from an option, a method annotation,
an annotation on the repository or an annotation on the entity class.
All these possibilities are handle by PseudoArgs in the
OperationSupport implementation. That scope/collection are passed
into decodeEntity(). The scope/collection of the child can only come
from an annotation on the entity class. The scope/collection of the
parent and child are uses as follows:
1) Both the parent and the chold have non-default collections
It's possible that the scope for the parent was set with an annotation on
a repository method, the entity class or the repository class or a query
option. Since there is no means to set the scope of the child class by the
method, repository class or query option (only the annotation) we assume
that the (possibly) dynamic scope of the entity would be a better choice
as it is logical to put collections to be joined in the same scope.
2) The parent has a collection (and therefore a scope as well), but the
child does not have a collection. Use the lhScope and lhCollection for
the entity. The child is just the bucket.
3) The parent does not have a collection (or scope), but child does have a
collection. Using the same (default) scope for the child would mean
specifying a non-default collection in a default scope - which is not
allowed. So use the scope and collection from the child class.
4) Neither have collections, just use the bucket.
Closes#1325.
When a derived query is being created and there is a predicate on
a meta-field ( meta().id, cas, expiry), translate that field
(i.e. id -> meta().id) *without* the bucket or collection name,
as it might apply to a collelction which we do not know yet
(for instance, if there is a withCollection() specified)..
This is fine, because in a derived query, meta() without the
bucket or collection name is unambigous.
