> Excellent, note that this should count each attribute value as one result,
> whether from the same document, or multiple documents.
Done.
> Given your earlier answers about mailing list modelling, I should ask how
> list-valued attributes are supported? Do just expand to a comma-separated
> list of the underlying values (I'd expect yes)?
Guess I forgot to include that patch the last time. But yes. for example, if a
mailing list is formed like:
{ "name": "[email protected]", "active": 1, "createdAt": ISODate("<some_date>"),
"addresses": [
"[email protected]", "[email protected]" ] }
then:
filter = { "name": "%s", "active": 1 }
return_attribute = addresses
for key "[email protected]" will return:
[email protected],[email protected]
Regards
Hamid Maadani
June 24, 2022 11:32 AM, "Viktor Dukhovni" <[email protected]> wrote:
> On Thu, Jun 23, 2022 at 06:13:05PM +0000, Hamid Maadani wrote:
>
>> The code is updated. Now:
>> - It accounts for the 'domain' parameter
>> - It requires a JSON formatted 'filter' parameter (no more search_key)
>
> Good.
>
>> - It uses comma-separated 'result_attribute' to return fields off of query
>> results.
>> The result will be a comma-separated string if multiple results present.
>> - It uses 'result_format' attribute to format the result
>
> I think this will be the most natural stratghtforward option for most users.
>
>> - It uses 'expansion_limit' attribute to control number of results being
>> returned
>
> Excellent, note that this should count each attribute value as one
> result, whether from the same document, or multiple documents.
>
>> - mongoc_client_pool_t has been converted to mongoc_client_t
>> - Each dict has it's own mongoc_client_t, to account for different backend
>> databases.
>
> Good.
>
>> - advanced projections are commented out for now, and not supported.
>
> Thanks. This can be and may need to be considered later.
>
>> I am still conflicted about the 'result_attribute' + 'result_format'
>> combination.
>> I understand what 'result_format' is used for. However, this can be done
>> inside projections
>> as well. I fail to see the advantage of the combo, since it will not "guide"
>> users to return
>> fields of the same "type". What are we solving for here? simplicity?
>> backwards compatibility?
>
> Projections are a much more complex "programming language", that should
> not required in the simplest use-cases where attribute values are used
> as-is, or with minor static decorations.
>
> Given your earlier answers about mailing list modelling, I should ask
> how list-valued attributes are supported? Do just expand to a
> comma-separated list of the underlying values (I'd expect yes)?
>
> --
> Viktor;.
