Return value of select and possible hooks

[Meikel Brandmeyer]

Hi Mark,

here the discussion so far:

>>> Meikel:
>>> currently a :select with the :only option returns a vector.
>>> This is a little bit annoying because I often have to turn it
>>> back into a map. My use case is that I restrict the fields
>>> in a query and then run some map-reduce kind of function
>>> over the result to aggregate the information spread over
>>> the query results. Using the query result verbatim is rather
>>> seldom for me. So I could live with a
>>>
>>> (map vals (client [:select :foo {:only [:OneField]}])).
>>
>> Mark:
>> Thanks for your thoughts on the vals vs. map issue. The
>> motivation for returning an array of values instead of a map
>> when select is used is that it reduces the bloat on result
>> set for queries returning lots of rows with few attributes. For
>> example, [:select :pages {:limit 50 {:only [:id :title]}}]. A user
>> can go from an array-based representation to a map-based
>> one if they're OK with the space hit, but you can't efficiently
>> go the other way without having to incur that cost initially. For
>> now I'd like to keep the array-of-value semantics. I have some
>> thoughts about how the problems you describe could be
>> ameliorated in the client library layer, but the're yet well-developed.
>> I'll let you know if my thinking on this topic changes or expands.
>
> Meikel:
> maybe one could pass the client some coercing function. This
> could do arbitrary things like turning the result into a map again,
> or convert columns into numbers or keywords, or whatever. Basically
> some hook which the user of the library can provide to modify a
> row just after it is read and before it gets passed on in the system.

I find myself doing such coercions a lot. Eg. I have some columns
which contain a small variety of well-defined values. These I would
like to turn into keywords (or at least some interned string) to safe
on memory. (Ok. Maybe premature optimisation). Such a case
would be a candidate for some after-read pre-process hook.

Sincerely
Meikel

[Mark McGranaghan]

I think the best way to go forward with this is to suggest a simple
example of what this would look like from a client api perspective.
I'm not sure that I'd want to include it in fleetdb.client yet, but it
will at least help me understand better what you're trying to do.

- Mark