Skip to content

Add collections support to N1qlJoin. #1333

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Feb 15, 2022
Merged

Add collections support to N1qlJoin. #1333

merged 2 commits into from
Feb 15, 2022

Conversation

mikereiche
Copy link
Collaborator

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.

  • You have read the Spring Data contribution guidelines.
  • There is a ticket in the bug tracker for the project in our JIRA.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@mikereiche mikereiche requested a review from daschl February 10, 2022 04:56
daschl
daschl reviewed Feb 15, 2022
View reviewed changes
src/main/java/org/springframework/data/couchbase/core/ReactiveTemplateSupport.java
public interface ReactiveTemplateSupport {

Mono<CouchbaseDocument> encodeEntity(Object entityToEncode);

<T> Mono<T> decodeEntity(String id, String source, long cas, Class<T> entityClass);
<T> Mono<T> decodeEntity(String id, String source, long cas, Class<T> entityClass, String scope, String collection);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume our template support classes are not public API so we can break them by extending?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. They are public. So I'll keep make a method with the old signature to call this one.

daschl
daschl reviewed Feb 15, 2022
View reviewed changes
src/main/java/org/springframework/data/couchbase/core/convert/join/N1qlJoinResolver.java Outdated
// choice as it is logical to put collections to be joined in the same scope. Note that lhScope
// is used for both keyspaces.
return new KeySpacePair(lhCollection,
x(x("default") + ":" + i(bucketName) + "." + i(lhScope) + "." + i(lhCollection)), //
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the default: needed? I think n1ql can infer that if not provided? Maybe I'm wrong though..

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your are correct. Removed.

daschl
daschl reviewed Feb 15, 2022
View reviewed changes
Copy link
Contributor

@daschl daschl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, just a couple comments

@mikereiche
Add collections support to N1qlJoin.
0535004 
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.
@mikereiche mikereiche force-pushed the datacouch_1325_collection_support_for_n1qljoin branch from ff45cdb to 0535004 Compare February 15, 2022 19:36
@mikereiche mikereiche merged commit fc075cc into main Feb 15, 2022
mikereiche added a commit that referenced this pull request Feb 16, 2022
@mikereiche
Add collections support to N1qlJoin. (#1333)
2e49741 
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.
mikereiche added a commit that referenced this pull request Feb 16, 2022
@mikereiche
Add collections support to N1qlJoin. (#1333)
cdf02cb 
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.
@mikereiche mikereiche deleted the datacouch_1325_collection_support_for_n1qljoin branch April 11, 2022 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@daschl daschl daschl left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

@N1qlJoin and couchbase collections
2 participants
@mikereiche @daschl