You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of creating a new builder and a new config object (and doing all the merging) for every operation with a DynamoDBMapperConfig parameter, AbstractDynamoDBMapper should cache and reuse these configurations. WeakHashMaps (with optional SoftReferences) should do the trick, or use some third party caching solution.
As an intermediate but also more secure solution, you might even extend DynamoDBMapperConfig with a (boolean) shouldCache field, and cache only these configurations.
Basically you should do the same with all of your *Config classes and wherever you might have the possibility to reuse objects instead of creating functional duplicates (in the whole sdk).
(And of course to benefit from it, your users should use reusable (e.g. static/singleton) config parameters, so you might wanna propagate this in the javadoc too.)
The text was updated successfully, but these errors were encountered:
the SDK team has reviewed the feature request list for V1, and since they're concentrating efforts on V2 new features they decided to not implement this one in V1. It's still being considered for the DynamoDB Mapper refactor in V2, see the referenced issue above. I'll go ahead and close this one.
Please feel free to comment on the V2 issue with your use case, and reach out if you have further questions.
Instead of creating a new builder and a new config object (and doing all the merging) for every operation with a
DynamoDBMapperConfig
parameter,AbstractDynamoDBMapper
should cache and reuse these configurations. WeakHashMaps (with optional SoftReferences) should do the trick, or use some third party caching solution.As an intermediate but also more secure solution, you might even extend
DynamoDBMapperConfig
with a (boolean)shouldCache
field, and cache only these configurations.Basically you should do the same with all of your *Config classes and wherever you might have the possibility to reuse objects instead of creating functional duplicates (in the whole sdk).
(And of course to benefit from it, your users should use reusable (e.g. static/singleton) config parameters, so you might wanna propagate this in the javadoc too.)
The text was updated successfully, but these errors were encountered: