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