[DATAMONGO-1695] Make sure GridFsResource.getContentType() reads type from new location within file metadata Created: 18/May/17  Updated: 14/Jun/17  Resolved: 18/May/17

Status: Closed
Project: Spring Data MongoDB
Component/s: Mapping / Conversion
Affects Version/s: 2.0 M3 (Kay)
Fix Version/s: 2.0 M4 (Kay)

Type: Bug Priority: Major
Reporter: Juergen Zimmermann Assignee: Oliver Drotbohm
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Last updater: Mark Paluch
Sprint: Kay M3

 Description   

The implementation of GridFsResource.getContentType() in version 1.10.3.RELEASE is

return file.getContentType();

However, in Spring Data MongoDB 2.0.0.M3 the contentType is stored inside metadata with the key type. Therefore, the implementation of GridFsResource.getContentType() should be

return file.getMetadata().getString("type")



 Comments   
Comment by Oliver Drotbohm [ 18/May/17 ]

This is fundamentally a driver issue as nothing changed in Spring Data except an upgrade of the driver. Can you elaborate on "broken", i.e. the effects that this has? I see that the underlying call to file.getContentType() is deprecated, but especially as it is deprecated I assumed it would still continue to return the proper value. I've filed a ticket for the Java driver to improve here. We can certainly move to the suggested method call, but ultimately this feels like a huge step backwards as we need to bake much more knowledge about the internal structure of GridFsFile into our code rather than the method just looking up the value from the right place. I mean, that's exactly what encapsulation is meant for.

Comment by Oliver Drotbohm [ 18/May/17 ]

Looks like we'll have to live with it. GridFsTemplate sets the content type itself in the store(…) method. I'm gonna extract that that key into a constant so that we make sure we write and read from the same place. I'll probably also rename the key to _contentType as type is much more likely to cause a collision with potential other metadata fields.

Comment by Juergen Zimmermann [ 18/May/17 ]

Why is org.springframework.data.mongodb.gridfs.GridFsTemplate storing the content type not separately as before in Spring Data 1.x?
https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/gridfs/GridFsTemplate.java#L169 is the line where the content type is stored as part of the metadata using the key type.

Comment by Oliver Drotbohm [ 18/May/17 ]

Because previously there had been a method setContentType(…) on MongoDB's GridFsFile which we used to set the type. They removed the former method and deprecated the latter so that you could still read the content types for files already saved through the old APIs but write it to the legacy place anymore.

The fix that's coming in a minute is now going to write and read from _contentType primarily falling back to the legacy lookup if nothing is found in there.

Comment by Oliver Drotbohm [ 18/May/17 ]

That's in place now.

Generated at Sun Dec 08 06:17:41 UTC 2019 using Jira 7.13.8#713008-sha1:1606a5c1e7006e1ab135aac81f7a9566b2dbc3a6.