DATACOUCH-588 - Part 2 of framework changes. Add support for projecti… #1040

mikereiche · 2021-01-07T00:16:33Z

…on and distinct.

Support for projection is only for properties of the top-level entity. For
instance, in UserSubmission, only the properties below can be specified in
the projection. Projection support does not provide means of specifying
something like address.street - you can only project (or not project) the
whole address property. However, the address type in your resultType could
have a subset of the properties in Address.

If the corresponding submissions in the resultType
contained only the userId property

public class UserSubmission extends ComparableEntity {
private String id;
private String username;
private List roles;
private Address address;
private List submissions;

Support for Distinct - I have appropriated the MongoDB model for Distinct.
It defines a separate DistinctOperationSupport class (within
ExecutableFindByQuerySupport) which supports the distinct( distinctFields )
api and execution. The DistinctOperationSupport class has only a
distinctFields member, and a 'delegate' member, which is an
ExecutableFindByQuerySupport object. TBH, I don't see the advantage
over simply adding a distinctFields member to ExecutableFindByQuerySupport

Amend #1 - changes as discussed in Pull Request
- clean up test entity types

Amend #2

Eliminate DistinctOperationSupport class. In MongoDB, only distinct on a single field is supported, so the returnType from distinct was very different from the returnType of other query operations (all(), one() etc. (but so is count(), and it doesn't need it's own class)). In Couchbase, distinct on any fields in the entity is allowed - so the returned type could be the domainType or resultType. And as(resultType) still allows any resultType to be specified. This makes it unnecessary to have combinations of interfaces such as DistinctWithProjection and DistinctWithQuery.
Clean up the interfaces in ExecutableFindByQuery. There are two types of interfaces (a) the TerminatingFindByQuery which has the one(), oneValue() first(), firstValue(), all(), count(), exists() and stream(); and (b) the option interfaces (FindByQueryWithConsistency etc), which are essentially with-er interfaces. The changes are:

make all the with-er interfaces base interfaces instead of chaining them together. (I don't know why there isn't simply one interface with all the with-er methods).
make the ExecutableFindByQuery interface extend the Terminating interface and all the with-er interfaces.

Amend #3

Add execution support for collections

Amend #4

Add tests for collections. This includes a new CollectionAwareIntegrationTests class which extends a new JavaIntegratationTests class which extends the existing ClusterAwareIntegrationTests.
Fixed up several issues collections issues that were uncovered by the tests.
Did further cleanup of OperationSupport interfaces.
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 · 2021-01-07T21:15:59Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

+	/**
+	 * @author Michael Reiche
+	 */
+	static class DistinctOperationSupport<T> implements TerminatingDistinct<T> {


This DistinctOperationSupport is appropriated from MongoDB. I have a hard time understanding why a new OperationSupport class is better than simply following the pattern of scanConsistency and collections - just adding a distinctFields member to FindByQueryOperationSupport and leveraging it throughout.
The issue is even bigger in the Reactive class, where the all() and one() methods are duplication almost verbatim.

Right -- I was wondering something similar .. maybe this is worth discussing with @mp911de before we get this in .. I bet there was a reason and maybe it's specific to mongo or history?

mikereiche · 2021-01-07T21:17:15Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

@@ -140,55 +140,36 @@
 		 * @return new instance of {@link FindWithProjection}.
 		 * @throws IllegalArgumentException if resultType is {@literal null}.
 		 */
-		<R> FindByQueryWithQuery<R> as(Class<R> resultType);
+		<R> FindWithProjection<R> as(Class<R> resultType);


the name FindByQueryWithProjection would be more consistent with the other FindByQuery interface names.
Same with FindByQueryWithDistinct vs. FindWithDistinct. MongoDB has only Find, while Couchbase has FindById and FindByQuery.

mikereiche · 2021-01-07T21:25:40Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

+		 *
+		 * @param scanConsistency the custom scan consistency to use for this query.
+		 */
+		TerminatingDistinct<Object> consistentWith(QueryScanConsistency scanConsistency);


This method should be named withConsistency(), but the method is already named 'consistentWith()' elsewhere. This is a breaking change but should be fixed at some point, as the method consistentWith() (not yet implemented) should take mutation tokens from a previous mutation operation.

could we just add another consistentWith overload that takes mutation tokens? Then we don't need to break anything and we just carry it forward?

That's a good idea.
In a separate branch, I'll add a withConsistency(QueryScanConsistency) and deprecate the consistentWith(QueryScanConsistency). Then in a future major release, remove it, leaving only the appropriate withConsistency(QueryScanConsistency) and consistentWith(mutation tokens).

mikereiche · 2021-01-07T21:38:41Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

-		return new ExecutableFindByQuerySupport<>(template, domainType, ALL_QUERY, QueryScanConsistency.NOT_BOUNDED,
-				"_default._default");
+		return new ExecutableFindByQuerySupport<T>(template, domainType, domainType, ALL_QUERY,
+				QueryScanConsistency.NOT_BOUNDED, null);


here the 'default' resultType for projection is the domainType. This is convenient, but it eliminates the the possibility of having a null resultType. I'm content to keep it this way.
I was thinking of the issue with Expiry, where always having a non-null expiry made it impossible to handle all of (1) default value; (2) override with annotation; (3) override with fluent method including undoing the default value. I don't think that needs to be handled for resultType, but it falls in the same pattern.
I changed the default collection to be null as that did not require any additional code changes, but changing the default resultType to null would require other changes.

Yeah, maybe in the worst case we need to come up with a special "null" type of sorts

mikereiche · 2021-01-07T21:41:08Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

 	}

 	/**
 	 * Distinct Find support.
 	 *
-	 * @author Christoph Strobl
-	 * @since 2.1
+	 * @author Michael Reiche
 	 */
 	interface FindDistinct {


As above - FindByQueryWithDistinct would be more consistent than FindDistinct

so do you suggest we make those changes? I guess since it is additive it won't be breaking anyone?

mikereiche · 2021-01-07T21:42:36Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

-		 * {@link }.</dd>
-		 * <dt>{@link }</dt>
-		 * <dd>Using {@link } allows retrieval of the raw driver specific format, which returns eg. {@link }.</dd>
-		 * </dl>


The Couchbase implementations for Projection and Distinct are much simpler than the MongoDB implementations. The MongoDB implementations would need to bring in about 5,000 lines of code from QueryMapper and its dependencies.

mikereiche · 2021-01-07T21:47:52Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperationSupport.java

+			@Override
+			public Flux<T> all() {
+				return Flux.defer(() -> {
+					String statement = delegate.assembleEntityQuery(false, distinctFields);


The additional 'distinctFields' argument to assembleEntityQuery() is the only difference between DistinctOperationSupport and ReactiveFindByQueryOperationSupport. I don't understand why Mongo decided to create a whole new DistinctOperationSupport class. It seems much more complicated than it needs to be.

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperationSupport.java

mikereiche · 2021-01-07T21:49:52Z

src/main/java/org/springframework/data/couchbase/core/query/Query.java

@@ -44,7 +44,7 @@
 */
 public class Query {

-	private final List<QueryCriteria> criteria = new ArrayList<>();
+	private final List<QueryCriteriaDefinition> criteria = new ArrayList<>();


this is changed to use the interface instead of the class.

mikereiche · 2021-01-07T21:52:27Z

src/main/java/org/springframework/data/couchbase/core/query/Query.java

+	public String toN1qlSelectString(ReactiveCouchbaseTemplate template, Class domainClass, Class returnClass,
+			boolean isCount, String[] distinctFields) {
+		StringBasedN1qlQueryParser.N1qlSpelValues n1ql = getN1qlSpelValues(template, domainClass, returnClass, isCount,
+				distinctFields);


We now need the projection class (returnClass) and distinctFields to produce the 'select' string.

daschl · 2021-01-08T05:57:39Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

+
+		/*
+		 * (non-Javadoc)
+		 * @see org.springframework.data.mongodb.core.ExecutableFindOperation.DistinctWithProjection#as(java.lang.Class)


mentions mongo?

oops. I searched all the files in my commit and fixed them.

daschl · 2021-01-08T05:58:11Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

+
+		/*
+		 * (non-Javadoc)
+		 * @see org.springframework.data.mongodb.core.ExecutableFindOperation.DistinctWithQuery#matching(org.springframework.data.mongodb.core.query.Query)


more mongo mentions - there are more but I won't ping you on all of them in this review

daschl · 2021-01-08T06:41:15Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

 	}

 	/**
 	 * Distinct Find support.
 	 *
-	 * @author Christoph Strobl
-	 * @since 2.1
+	 * @author Michael Reiche
 	 */
 	interface FindDistinct {


so do you suggest we make those changes? I guess since it is additive it won't be breaking anyone?

daschl · 2021-01-08T06:42:32Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperation.java

+		 *
+		 * @param scanConsistency the custom scan consistency to use for this query.
+		 */
+		TerminatingDistinct<Object> consistentWith(QueryScanConsistency scanConsistency);


could we just add another consistentWith overload that takes mutation tokens? Then we don't need to break anything and we just carry it forward?

daschl · 2021-01-08T06:45:26Z

...est/java/org/springframework/data/couchbase/core/CouchbaseTemplateQueryIntegrationTests.java

+				.consistentWith(QueryScanConsistency.REQUEST_PLUS).matching(specialUsers).all();
+		assertEquals(1, foundUsers.size());
+
+		final List<UserJustLastName> foundUsersReactive = reactiveCouchbaseTemplate.findByQuery(User.class)


Midway in review I have a basic question.. so here we have:

reactiveCouchbaseTemplate.findByQuery(User.class).as(UserJustLastName.class)

what is the reason we could not just do

reactiveCouchbaseTemplate.findByQuery(UserJustLastName.class)

I assume there is good reason, but I probably don't understand it fully

Good question. Because the documents are stored with _class = "somepackage.User" and they would not be selected by the query as it would have WHERE _class = "somepackage.UserJustLastName". This is also the reason that there is no as(otherClass) method for ExecutableFindById - it just selection on id.

daschl · 2021-01-08T06:48:26Z

...ain/java/org/springframework/data/couchbase/repository/query/StringBasedN1qlQueryParser.java

+		if (distinctFields != null) {
+			String distinctFieldsStr = distinctFields.length == 0 ? projectedFields : getDistinctFields(distinctFields);
+			if (isCount) {
+				// only works with one field - MB43475


can we raise an explicit exception to the user if its more than one field?

This was my mistake. The syntax for a sequence in n1ql is DISTINCT { prop1, prop2 ... }
I was trying to use SQL syntax of DISTINCT prop1, prop2 ...
I've closed MB43475 and will fix my code.

daschl · 2021-01-08T06:55:14Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

-		return new ExecutableFindByQuerySupport<>(template, domainType, ALL_QUERY, QueryScanConsistency.NOT_BOUNDED,
-				"_default._default");
+		return new ExecutableFindByQuerySupport<T>(template, domainType, domainType, ALL_QUERY,
+				QueryScanConsistency.NOT_BOUNDED, null);


Yeah, maybe in the worst case we need to come up with a special "null" type of sorts

daschl · 2021-01-08T06:56:14Z

...main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperationSupport.java

+	/**
+	 * @author Michael Reiche
+	 */
+	static class DistinctOperationSupport<T> implements TerminatingDistinct<T> {


Right -- I was wondering something similar .. maybe this is worth discussing with @mp911de before we get this in .. I bet there was a reason and maybe it's specific to mongo or history?

mikereiche · 2021-01-13T04:59:47Z

src/main/java/org/springframework/data/couchbase/core/ExecutableFindByIdOperation.java

@@ -46,28 +46,29 @@

 	}

-	interface FindByIdWithCollection<T> extends TerminatingFindById<T> {
+	interface FindByIdWithCollection<T> {



I've removed as much of the dependencies as possible.
There's no need for every interface to extend TerminatingFindById. It's sufficient for ExecutableFindById to extend it.

mikereiche · 2021-01-13T05:01:05Z

src/main/java/org/springframework/data/couchbase/core/ExecutableFindByIdOperation.java


 		/**
 		 * Allows to specify a different collection than the default one configured.
 		 *
 		 * @param collection the collection to use in this scope.
 		 */
-		TerminatingFindById<T> inCollection(String collection);
+		ExecutableFindById<T> inCollection(String collection);



if each with-er returns ExecutableFindById, then there is no need to chain the interfaces.

mikereiche · 2021-01-13T05:02:50Z

src/main/java/org/springframework/data/couchbase/core/ExecutableFindByIdOperationSupport.java

 			Assert.hasText(collection, "Collection must not be null nor empty.");
 			return new ExecutableFindByIdSupport<>(template, domainType, collection, fields);
 		}

 		@Override
-		public FindByIdWithCollection<T> project(String... fields) {
+		public ExecutableFindById<T> project(String... fields) {
 			Assert.notEmpty(fields, "Fields must not be null nor empty.");


I find it strange that FindById does projection by project(fields) instead of as(returnType) like everything else.

mikereiche · 2021-01-13T05:03:52Z

src/main/java/org/springframework/data/couchbase/core/ExecutableFindByQueryOperation.java

+		 */
+		default ExecutableFindByQuery<T> matching(QueryCriteriaDefinition criteria) {
+			return matching(Query.query(criteria));
+		}


mongo provides a matching(Criteria) method.

mikereiche · 2021-01-13T05:15:00Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByIdOperationSupport.java

@@ -62,6 +62,8 @@
 		public Mono<T> one(final String id) {
 			return Mono.just(id).flatMap(docId -> {
 				GetOptions options = getOptions().transcoder(RawJsonTranscoder.INSTANCE);
+				// Instead of project(fields), I think this should be implemented the same as
+				// FindByQuery as(resultType), and the list of fields should be the properties of resultType


Here is the run-time for FindById.project() that I questioned above.

mikereiche · 2021-01-13T05:24:10Z

src/main/java/org/springframework/data/couchbase/core/ReactiveFindByQueryOperationSupport.java

+						row.removeKey(TemplateUtils.SELECT_CAS);
+					}
+					return template.support().decodeEntity(id, row.toString(), cas, returnType);
+				});


If a collection has been specified, execute on the scope, otherwise execute on the cluster.

mikereiche · 2021-01-13T06:13:34Z

src/main/java/org/springframework/data/couchbase/core/ExecutableFindByAnalyticsOperation.java

+
+	}
+
+	interface ExecutableFindByAnalytics<T> extends FindByAnalyticsConsistentWith<T>, FindByAnalyticsWithConsistency<T> {}


Deprecate consistentWith(), add withConsistency(). This is done for all interfaces that have consistentWith()

daschl

looks good to me, the only thing I'm unsure on are the interface extension changes -- please triple check that those are not breaking any users out there...

…on and distinct. Support for projection is only for properties of the top-level entity. For instance, in UserSubmission, only the properties below can be specified in the projection. Projection support does not provide means of specifying something like address.street - you can only project (or not project) the whole address property. However, the address type in your resultType could have a subset of the properties in Address. If the corresponding submissions in the resultType contained only the userId property public class UserSubmission extends ComparableEntity { private String id; private String username; private List<String> roles; private Address address; private List<Submission> submissions; Support for Distinct - I have appropriated the MongoDB model for Distinct. It defines a separate DistinctOperationSupport class (within ExecutableFindByQuerySupport) which supports the distinct( distinctFields ) api and execution. The DistinctOperationSupport class has only a distinctFields member, and a 'delegate' member, which is an ExecutableFindByQuerySupport object. TBH, I don't see the advantage over simply adding a distinctFields member to ExecutableFindByQuerySupport Amend #1 - changes as discussed in Pull Request - clean up test entity types Amend #2 - Eliminate DistinctOperationSupport class. In MongoDB, only distinct on a single field is supported, so the returnType from distinct was very different from the returnType of other query operations (all(), one() etc. (but so is count(), and it doesn't need it's own class)). In Couchbase, distinct on any fields in the entity is allowed - so the returned type could be the domainType or resultType. And as(resultType) still allows any resultType to be specified. This makes it unnecessary to have combinations of interfaces such as DistinctWithProjection and DistinctWithQuery. - Clean up the interfaces in ExecutableFindByQuery. There are two types of interfaces (a) the TerminatingFindByQuery which has the one(), oneValue() first(), firstValue(), all(), count(), exists() and stream(); and (b) the option interfaces (FindByQueryWithConsistency etc), which are essentially with-er interfaces. The changes are: 1) make all the with-er interfaces base interfaces instead of chaining them together. (I don't know why there isn't simply one interface with all the with-er methods). 2) make the ExecutableFindByQuery interface extend the Terminating interface and all the with-er interfaces. Amend #3 - Add execution support for collections Amend #4 - Add tests for collections. This includes a new CollectionAwareIntegrationTests class which extends a new JavaIntegratationTests class which extends the existing ClusterAwareIntegrationTests. - Fixed up several issues collections issues that were uncovered by the tests. - Did further cleanup of OperationSupport interfaces. Amend #5 - Revert changes to interfaces in *Operation - Sorted interfaces in same order for consistency (because of the chaining of interfaces, fluent methods must be called in order).

…on and distinct. (spring-projects#1040) Support for projection is only for properties of the top-level entity. For instance, in UserSubmission, only the properties below can be specified in the projection. Projection support does not provide means of specifying something like address.street - you can only project (or not project) the whole address property. However, the address type in your resultType could have a subset of the properties in Address. If the corresponding submissions in the resultType contained only the userId property public class UserSubmission extends ComparableEntity { private String id; private String username; private List<String> roles; private Address address; private List<Submission> submissions; Support for Distinct - I have appropriated the MongoDB model for Distinct. It defines a separate DistinctOperationSupport class (within ExecutableFindByQuerySupport) which supports the distinct( distinctFields ) api and execution. The DistinctOperationSupport class has only a distinctFields member, and a 'delegate' member, which is an ExecutableFindByQuerySupport object. TBH, I don't see the advantage over simply adding a distinctFields member to ExecutableFindByQuerySupport Amend spring-projects#1 - changes as discussed in Pull Request - clean up test entity types Amend spring-projects#2 - Eliminate DistinctOperationSupport class. In MongoDB, only distinct on a single field is supported, so the returnType from distinct was very different from the returnType of other query operations (all(), one() etc. (but so is count(), and it doesn't need it's own class)). In Couchbase, distinct on any fields in the entity is allowed - so the returned type could be the domainType or resultType. And as(resultType) still allows any resultType to be specified. This makes it unnecessary to have combinations of interfaces such as DistinctWithProjection and DistinctWithQuery. - Clean up the interfaces in ExecutableFindByQuery. There are two types of interfaces (a) the TerminatingFindByQuery which has the one(), oneValue() first(), firstValue(), all(), count(), exists() and stream(); and (b) the option interfaces (FindByQueryWithConsistency etc), which are essentially with-er interfaces. The changes are: 1) make all the with-er interfaces base interfaces instead of chaining them together. (I don't know why there isn't simply one interface with all the with-er methods). 2) make the ExecutableFindByQuery interface extend the Terminating interface and all the with-er interfaces. Amend spring-projects#3 - Add execution support for collections Amend spring-projects#4 - Add tests for collections. This includes a new CollectionAwareIntegrationTests class which extends a new JavaIntegratationTests class which extends the existing ClusterAwareIntegrationTests. - Fixed up several issues collections issues that were uncovered by the tests. - Did further cleanup of OperationSupport interfaces. Amend spring-projects#5 - Revert changes to interfaces in *Operation - Sorted interfaces in same order for consistency (because of the chaining of interfaces, fluent methods must be called in order). Co-authored-by: mikereiche <michael.reiche@couchbase.com>

…on and distinct. (#1040) Support for projection is only for properties of the top-level entity. For instance, in UserSubmission, only the properties below can be specified in the projection. Projection support does not provide means of specifying something like address.street - you can only project (or not project) the whole address property. However, the address type in your resultType could have a subset of the properties in Address. If the corresponding submissions in the resultType contained only the userId property public class UserSubmission extends ComparableEntity { private String id; private String username; private List<String> roles; private Address address; private List<Submission> submissions; Support for Distinct - I have appropriated the MongoDB model for Distinct. It defines a separate DistinctOperationSupport class (within ExecutableFindByQuerySupport) which supports the distinct( distinctFields ) api and execution. The DistinctOperationSupport class has only a distinctFields member, and a 'delegate' member, which is an ExecutableFindByQuerySupport object. TBH, I don't see the advantage over simply adding a distinctFields member to ExecutableFindByQuerySupport Amend #1 - changes as discussed in Pull Request - clean up test entity types Amend #2 - Eliminate DistinctOperationSupport class. In MongoDB, only distinct on a single field is supported, so the returnType from distinct was very different from the returnType of other query operations (all(), one() etc. (but so is count(), and it doesn't need it's own class)). In Couchbase, distinct on any fields in the entity is allowed - so the returned type could be the domainType or resultType. And as(resultType) still allows any resultType to be specified. This makes it unnecessary to have combinations of interfaces such as DistinctWithProjection and DistinctWithQuery. - Clean up the interfaces in ExecutableFindByQuery. There are two types of interfaces (a) the TerminatingFindByQuery which has the one(), oneValue() first(), firstValue(), all(), count(), exists() and stream(); and (b) the option interfaces (FindByQueryWithConsistency etc), which are essentially with-er interfaces. The changes are: 1) make all the with-er interfaces base interfaces instead of chaining them together. (I don't know why there isn't simply one interface with all the with-er methods). 2) make the ExecutableFindByQuery interface extend the Terminating interface and all the with-er interfaces. Amend #3 - Add execution support for collections Amend #4 - Add tests for collections. This includes a new CollectionAwareIntegrationTests class which extends a new JavaIntegratationTests class which extends the existing ClusterAwareIntegrationTests. - Fixed up several issues collections issues that were uncovered by the tests. - Did further cleanup of OperationSupport interfaces. Amend #5 - Revert changes to interfaces in *Operation - Sorted interfaces in same order for consistency (because of the chaining of interfaces, fluent methods must be called in order). Co-authored-by: mikereiche <michael.reiche@couchbase.com>

…1080) * DATACOUCH-588 - Part 2 of framework changes. Add support for projection and distinct. (#1040) Support for projection is only for properties of the top-level entity. For instance, in UserSubmission, only the properties below can be specified in the projection. Projection support does not provide means of specifying something like address.street - you can only project (or not project) the whole address property. However, the address type in your resultType could have a subset of the properties in Address. If the corresponding submissions in the resultType contained only the userId property public class UserSubmission extends ComparableEntity { private String id; private String username; private List<String> roles; private Address address; private List<Submission> submissions; Support for Distinct - I have appropriated the MongoDB model for Distinct. It defines a separate DistinctOperationSupport class (within ExecutableFindByQuerySupport) which supports the distinct( distinctFields ) api and execution. The DistinctOperationSupport class has only a distinctFields member, and a 'delegate' member, which is an ExecutableFindByQuerySupport object. TBH, I don't see the advantage over simply adding a distinctFields member to ExecutableFindByQuerySupport Amend #1 - changes as discussed in Pull Request - clean up test entity types Amend #2 - Eliminate DistinctOperationSupport class. In MongoDB, only distinct on a single field is supported, so the returnType from distinct was very different from the returnType of other query operations (all(), one() etc. (but so is count(), and it doesn't need it's own class)). In Couchbase, distinct on any fields in the entity is allowed - so the returned type could be the domainType or resultType. And as(resultType) still allows any resultType to be specified. This makes it unnecessary to have combinations of interfaces such as DistinctWithProjection and DistinctWithQuery. - Clean up the interfaces in ExecutableFindByQuery. There are two types of interfaces (a) the TerminatingFindByQuery which has the one(), oneValue() first(), firstValue(), all(), count(), exists() and stream(); and (b) the option interfaces (FindByQueryWithConsistency etc), which are essentially with-er interfaces. The changes are: 1) make all the with-er interfaces base interfaces instead of chaining them together. (I don't know why there isn't simply one interface with all the with-er methods). 2) make the ExecutableFindByQuery interface extend the Terminating interface and all the with-er interfaces. Amend #3 - Add execution support for collections Amend #4 - Add tests for collections. This includes a new CollectionAwareIntegrationTests class which extends a new JavaIntegratationTests class which extends the existing ClusterAwareIntegrationTests. - Fixed up several issues collections issues that were uncovered by the tests. - Did further cleanup of OperationSupport interfaces. Amend #5 - Revert changes to interfaces in *Operation - Sorted interfaces in same order for consistency (because of the chaining of interfaces, fluent methods must be called in order). Co-authored-by: mikereiche <michael.reiche@couchbase.com> * DATACOUCH-588 - after cherry-pick, remove reference to 4.2 method deleteAllById(). Original pull request #1040

mikereiche requested a review from daschl January 7, 2021 00:16

mikereiche commented Jan 7, 2021

View reviewed changes

mikereiche force-pushed the datacouch_part_2_of_n_framework_projection_distinct branch 2 times, most recently from bcdd0f0 to 66015b2 Compare January 7, 2021 22:10

daschl suggested changes Jan 8, 2021

View reviewed changes

mikereiche force-pushed the datacouch_part_2_of_n_framework_projection_distinct branch 4 times, most recently from cc249c8 to a3f9b27 Compare January 13, 2021 04:55

mikereiche commented Jan 13, 2021

View reviewed changes

mikereiche force-pushed the datacouch_part_2_of_n_framework_projection_distinct branch from a3f9b27 to bd7e40e Compare January 13, 2021 06:10

mikereiche commented Jan 13, 2021

View reviewed changes

daschl approved these changes Jan 13, 2021

View reviewed changes

mikereiche force-pushed the datacouch_part_2_of_n_framework_projection_distinct branch 2 times, most recently from 7fc1de4 to 90fb286 Compare January 14, 2021 03:57

mikereiche force-pushed the datacouch_part_2_of_n_framework_projection_distinct branch from 90fb286 to 027ec93 Compare January 14, 2021 18:48

mikereiche merged commit 0e8d5a2 into master Jan 14, 2021

mikereiche mentioned this pull request Feb 16, 2021

DATACOUCH-588 - Part 2 of 2 refactoring for paging and projection. #1080

Merged

5 tasks


		}

		interface ExecutableFindByAnalytics<T> extends FindByAnalyticsConsistentWith<T>, FindByAnalyticsWithConsistency<T> {}

DATACOUCH-588 - Part 2 of framework changes. Add support for projecti… #1040

DATACOUCH-588 - Part 2 of framework changes. Add support for projecti… #1040

Uh oh!

Conversation

mikereiche commented Jan 7, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikereiche Jan 7, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikereiche Jan 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daschl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mikereiche commented Jan 7, 2021 •

edited

Loading

mikereiche Jan 7, 2021 •

edited

Loading

mikereiche Jan 8, 2021 •

edited

Loading