Closed pegotezzi closed 10 years ago
Hi there,
Perfect place to ask - no worries! :-)
Why non DynamoDB type data have to be manually converted by calling freeze instead of auto-magically done?
Good question. I normally prefer to avoid auto-magical conversions when possible, especially for APIs that deal with important data. Serialized forms are harder to query for/over, and they don't interop well with non-Faraday clients.
With auto serilization, it'd be possible to accidentally write data in an unexpected form. Without auto serialization, Faraday can just throw an exception on a non-native type and force users to think about the tradeoffs they want.
Does that make sense? BTW you can :refer
the freeze
fn if you use it an awful lot, that may help cut down on boilerplate.
They are just two different views, and I prefer to have a layer which knows how to serialize things - like GC rather than manual memory management.
Sure, it does not work well with non-Faraday clients when there are freeze calls.
I understand your design philosophy (And I've already made changes on my local machine so I will see :)
Thank for the answer!
Sure, no problem :-)
(I am not sure if this is a good place to ask. If not, sorry)
This is a design decision question. Why non DynamoDB type data have to be manually converted by calling freeze instead of auto-magically done? In this way, I don't need to know about freeze at all and can work in terms of 'Clojure types' always.
For example,
Why not: (far/put-item client-opts :mttable {:id ["abc" "def"]}) ;; internally call freeze here instead of (far/put-item client-opts :mttable {:id (far/freeze ["abc" "def"])})
Also (far/get-item client-opts :mttable {:id ["abc" "def"]}) ;; call freeze internally than (far/get-item client-opts :mttable {:id (far/freeze ["abc" "def"])})
Thanks!