Skip to content

DATAMONGO-1666 - Consider collection type in bulk DBRef fetching. #457

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

Closed
wants to merge 3 commits into from

Conversation

mp911de
Copy link
Member

@mp911de mp911de commented Apr 12, 2017

We now consider the property's collection type after bulk-fetching DBRefs before returning the actual result value. The issue got only visible if bulk fetching is possible and constructor creation is used. Setting the property value on through an property accessor works fine because the property accessor checks all values for assignability and potentially converts values to their target type. That's different for constructor creation.


Related ticket: DATAMONGO-1666.

mp911de added 2 commits April 12, 2017 16:55
…es List instead of collection type.

Prepare issue branch.
We now consider the property's collection type after bulk-fetching DBRefs before returning the actual result value. The issue got only visible if bulk fetching is possible and constructor creation is used. Setting the property value on through an property accessor works fine because the property accessor checks all values for assignability and potentially converts values to their target type. That's different for constructor creation.
@@ -913,7 +912,10 @@ private Object readCollectionOrArray(TypeInformation<?> targetType, List sourceV
}

if (!DBRef.class.equals(rawComponentType) && isCollectionOfDbRefWhereBulkFetchIsPossible(sourceValue)) {
return bulkReadAndConvertDBRefs((List<DBRef>) (List) (sourceValue), componentType, path, rawComponentType);
Copy link
Member

Choose a reason for hiding this comment

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

That's a funny one. I didn't even know casting something twice was allowed :D.

@odrotbohm
Copy link
Member

Looks good to me.

Some minor language level cleanups and removal of deprecated API usage.
christophstrobl pushed a commit that referenced this pull request Apr 13, 2017
We now consider the property's collection type after bulk-fetching DBRefs before returning the actual result value. The issue got only visible if bulk fetching is possible and constructor creation is used. Setting the property value on through an property accessor works fine because the property accessor checks all values for assignability and potentially converts values to their target type. That's different for constructor creation.

Original Pull Request: #457
christophstrobl added a commit that referenced this pull request Apr 13, 2017
Some minor language level cleanups and removal of deprecated API usage.

Original Pull Request: #457
christophstrobl pushed a commit that referenced this pull request Apr 13, 2017
We now consider the property's collection type after bulk-fetching DBRefs before returning the actual result value. The issue got only visible if bulk fetching is possible and constructor creation is used. Setting the property value on through an property accessor works fine because the property accessor checks all values for assignability and potentially converts values to their target type. That's different for constructor creation.

Original Pull Request: #457
@christophstrobl christophstrobl deleted the issue/DATAMONGO-1666 branch April 13, 2017 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants