This adds n1ql.scope and n1ql.collection spel expressions for
@Query so that n1ql.bucket doesn't need to be overloaded with
the collection name. This will make the bucket name available
in n1q.bucket.
This is a breaking change as queries that used n1ql.bucket to
get the collection name (especially in the case of pre-scope-
and-collection @Queries that (a) referenced n1ql.bucket instead
of referencing other spel expressions that include the
bucket/collection name; and (b) still worked after the
repository was moved from a bucket onto a collection by
virtue of n1ql.bucket having the value of the collection in
such instances.
Closes#1445.
Add BigDecimal converter, add converter tests for BigDecimal and BigInteger.
Since BigDecimail is not support, it cannot be used in the CustomerConverter tests.
So instead use ChoiceFormat for CustomConverter tests.
Closes#1439.
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.
