I came across an interesting case - when I use next.jdbc.optional together with the transit format and the response contains a collection of maps, I am basically unable to read any but the first map - the number of keys in each map can vary and I have no idea what the value at position 5 in map 3 represents. Has anyone solved this problem and found a way to use these two libraries simultaneously?
When the cache is enabled, if you write your data in full with the same writer you also have to read the data in full with the same reader.
Although I don't see how next.jdbc.optional is relevant here. So might be some other issue. If you provide some example data, it will become more apparent.
I forgot to mention that my concern is reading in the chrome console. This is relevant because without using this library, every map in the collection has the same number of keys. So I can look in the first map in body, see that the :key is at position 15, and then look in some other map at position 15 and see what the :key value is. This is problem when using next.jdbc.optional
I'm looking for a way to disable the cache, for dev purposes this would probably be good solution.
Use the :json-verbose format to disable the cache. Then each map will be represented as an object and not as an array, IIRC.
Alternatively, serialize each map with a new writer to have the cache only at the map level and not at the overall collection level.
If it's only for dev, then definitely go the :json-verbose route. I use it everywhere in development.
Awesome, thanks! I'd like to imagine what you mean by the second solution. If I cache at map level, I lose key readability, or not?
No, you'll simply have to use a reader per map as well. But I wouldn't recommend it. It was just a thought out loud. :)
Okay, as I understand it, I don't find that very useful. Anyway, thanks again