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;.
