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.
Remove unnecessary auditorAwareRef from test config as it causes
confusion. The property does not need to be preset for the auditorAwareRef
bean to be used.
The dateTimeProviderRef must be present for the provided
dateTimeProviderRef bean to be used.
Closes#1052.
Omit annotations from the repository and domaintype in
CrudMethodMetadata as they may be different for the same method.
The annotations from the repository and domaintype are obtained directly
in CouchbaseRepositoryBase.
Closes#1168.
Co-authored-by: mikereiche <michael.reiche@couchbase.com>
* Add support for scopes and collections for repositories.
Adds DynamicProxyable and DynamicInvocationHandler to
set scope/collection/options on PseudoArgs when calling
operations via repository interfaces.
Closes#963.
Co-authored-by: mikereiche <michael.reiche@couchbase.com>
1) the previous change (#955) to CouchbaseAuditingRegister intended to register
AuditingEntityCallback instead of AuditingEventListener but only changed the
name that AuditingEventListener was registered with. Since
AuditingEventListener does exactly the same thing as AuditingEntityCallback,
it behaved as those AuditingEntityCallback was being used.
2) It seems that the two mechanisms - EntityCallback and EventListener
both do more-or-less the same thing. I'm not sure why there are two
mechanisms to do the same thing.
3) Although the ReactiveAuditingEntityCallback mechanism is triggered
only for reactive operations and the non-reactive AuditingEntityCallback
is triggered only for non-reactive operations, the events are triggered
for both. Since there was a desire to have distinct callbacks for
reactive/non-reactive operations, I also made distinct events for
reactive/non-reactive operations. However both the reactive and non-reactive
event mechanisms are triggered for either reactive and non-reactive operations,
so it is necessary for the mechanism to determine if it should act on the
event.
4) Although there is an AbstractCouchbaseEventListener that is extended by
LoggingEventListener and ValidatingEventListener, AuditingEventListener does
not extend it (maybe it should).
Closes#1074.
Co-authored-by: mikereiche <michael.reiche@couchbase.com>
