[JAVA-2790] MapPropertyCodecProvider prevents custom extension Created: 23/Feb/18  Updated: 27/Oct/23  Resolved: 23/Feb/18

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: 3.6.3
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jesse van Houten Assignee: Ross Lawley
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi, our old custom ORM supported pojos with Maps with non-string keys, IF it was a ObjectId or if it was an enum (because both are rather easily converted to and from string).

The standard ORM model does not allow this and requires the key to be a String (MapPropertyCodecProvider).

Which is fine, but it throws an exception if the key is not a String. This prevents me from making a custom PropertyCodecProvider. Since the MapPropertyCodecProvider is higher up the chain...

I think MapPropertyCodecProvider should not throw an exception if the map key is not a string, and just pass it on to other PropertyCodecProvider.



 Comments   
Comment by Ross Lawley [ 23/Feb/18 ]

jessevanhouten good to hear its working.

Comment by Jesse van Houten [ 23/Feb/18 ]

I cannot close or remove this story, but I believe it should be considered closed or no-issue.

Comment by Jesse van Houten [ 23/Feb/18 ]

Sorry, you are correct. I did add a custom PropertyCodecProvider to check, but not to the one that was actually used. Thanks for your assistance

Comment by Ross Lawley [ 23/Feb/18 ]

Hi jessevanhouten,

Thanks for the ticket, seems like something is wrong, in 3.6.3 you should still be register your own custom PropertyCodecProvider as the user defined providers are checked first, then the defaults. There is a test case for such a model that has a Map<Integer, Integer> field.

Custom PropertyCodecProvider instances can be registered via the PropertyCodecProvider#Builder eg: Builder#register(PropertyCodecProvider).

Let me know if that is not the case,

Ross

Generated at Thu Feb 08 08:58:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.