-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
Map collection and fields for $lookup
/$graphLookup
aggregation stage against domain type
#4406
base: main
Are you sure you want to change the base?
Conversation
$lookup
/$graphLookup
aggregation stage against domain type
This commit enables using a type parameter to define the from collection of a lookup aggregation stage. In doing so we can derive the target collection name from the type and use the given information to also map the from field against the domain object to so that the user is able to operate on property names instead of the target db field name.
This commit enables using a type parameter to define the from collection of a graphLookup aggregation stage. In doing so we can derive the target collection name from the type and use the given information to also map the from field against the domain object to so that the user is able to operate on property names instead of the target db field name.
* @return never {@literal null}. | ||
* @since 4.2 | ||
*/ | ||
default String getMappedFieldName(Class<?> type, String field) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding another method that accepts a type, how about either AggregationOperationContext.withType(…)
or reusing getFields(Class<?> type)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A TypeBasedAggregationOperationContext
can reference a type but we need to be able to map against different types not necessarily being the root that we've been starting with. Also working with getFields
would do more than what we'd need.
We can see if we manage to expose more meaningful types than plain Strings
so that we're able to enhance the context with additional capabilities without having to add new methods every once in a while when we reach its limits.
@Override | ||
public String getMappedFieldName(Class<?> type, String field) { | ||
|
||
PersistentPropertyPath<MongoPersistentProperty> persistentPropertyPath = mappingContext.getPersistentPropertyPath(field, type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RelaxedTypeBasedAggregationOperationContext
doesn't consider any relaxed handling. Ideally, we could find an approach that embeds into our mandatory vs. relaxed field handling.
Reformatting, trailing whitespaces.
This commit enables using a type parameter to define the from collection of a
$lookup
/$graphLookup
aggregation stage. In doing so we can derive the target collection name from the type and use the given information to also map the from field against the domain object to so that the user is able to operate on property names instead of the target document field name.Resolves: #4379