search

replikativ / konserve

A clojuresque key-value/document store protocol with core.async.
Eclipse Public License 1.0
298 stars 25 forks source link

Performance update-in #72

Closed awb99 closed 1 year ago

awb99 commented 2 years ago

I have seen a lot of examples using k/assoc-in

Now I like the benefit of this. I can store different types of data with (k/assoc-in [:bar 1] 15) and (k/assoc-in [:bar 2] 100)

Wirh (k/get [:bar]) I then can get both 15 and 100. Its an easy way to track lists of different types.

Now the values 15 and 100 in practice would be quite big datastructures. And now my question is if every update-in will trigger a complete re-write if all the data in the list of :bar?

Thanks!

whilo commented 1 year ago

Yes, that is correct. If you want to write them separately you need to put them into different blobs. This can be achieved by using assoc instead. The first entry of the key vector in assoc-in determines the blob where things are stored. An adaptable mapping in form of categorical lenses would be possible, but I decided to fix it to keep things predictable.

whilo commented 1 year ago

I will close this for now, feel free to open more issues if you have further questions.