@N1qlJoin and couchbase collections #1325
Labels
type: bug
A general bug
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Hi @martin8877 - N1qlJoin hasn't been updated for collections. I'm looking at it now. |
mikereiche
added
type: bug
mikereiche
added a commit
that referenced
this issue
Feb 10, 2022
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.
5 tasks
mikereiche
added a commit
that referenced
this issue
Feb 15, 2022
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 issue
Feb 15, 2022
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 issue
Feb 16, 2022
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 issue
Feb 16, 2022
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Does
@N1qlJoinwork with entities annotated with@Collection?I tried simple join of two entities
@N1qlJoin(on = "lks.rightEntityId=meta(rks).id")(lks is in different collection than rks) and it does not work. An exception is thrown:Keyspace not found in CB datastore. It looks like the default collection is used.The text was updated successfully, but these errors were encountered: