>> If the result may contain quoted strings, then we need a smarter
>> parser than wnat mystrtok() does now.
>
> If multiple search columns are to be supported, with a mixture of
> strings and numeric values, .... Perhaps the search filter should remain
> a JSON object:
>
> query_filter = {user:"%s", active:1}
Couldn't agree more. If we have consensus on this, I will remove all the
shenanigans
for 'search_keys' and retain support for a mandatory JSON formatted 'filter'
parameter.
I'm always for simplifying things. Should it be called 'filter' or 'query' by
the way,
which one is preferred?
> I'd rename "result_key" to "result_attribute" and allow it to be
> multi-valued (multiple potential columns to retrieve from the returned
> object, either alternatives, or sometimes many from the same object).
>
> Also, the "client pool" is pointless, Postfix processes are not
> multi-threaded. Instead use a single dedicated (long-term) connection
> per open table, but be prepared to retry if the connection was
> unilaterally closed on the server side.
Will address these once I get the chance.
I usually use client pools, because of their thread safety (which is not needed
here) as well as
the more aggressive cluster monitoring operations they have by default compared
to the single
threaded mongoc_client_t. There is no need to manually monitor the connection
and make sure
server has closed it when using mongoc_client_pool_t. That being said, I have
nothing against the
use of mongoc_client_t. Will convert to that.
Question about the result_attributes, how should multi-columned multiple
results be returned?
For example, if 'result_attributes = username,password', for below result set
(filter = {"active":1}):
{"username":"hamid","password":"blah","active":1}
{"username":"wietse","password":"viktor","active":1}
Should it return:
hamid,blah,wietse,viktor
or:
hamid,blah
wietse,viktor
?
Regards
Hamid Maadani
June 17, 2022 2:03 PM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:
> On Fri, Jun 17, 2022 at 04:53:41PM -0400, Wietse Venema wrote:
>
>> Viktor Dukhovni:
>> Also, your parsing of the search_keys is hand-rolled, but should be
>> using mystrtok(3) to split the list on commas/whitespace, and
>> split_nameval(3) to split "key = value" pairs on "=".
>>
>> If the result may contain quoted strings, then we need a smarter
>> parser than wnat mystrtok() does now.
>
> If multiple search columns are to be supported, with a mixture of
> strings and numeric values, .... Perhaps the search filter should remain
> a JSON object:
>
> query_filter = {user:"%s", active:1}
>
> without support for:
>
> search_keys = user:"%s", active:1
>
> there's hardly much value in splitting these, and performing separate
> substitutions only add missing "{" and "}" front and back. The real
> value is multiple result attributes which are simple names:
>
> result_attribute = foo, bar, ...
>
> The key missing code is correct JSON quoting in expansion "%s".
>
> --
> Viktor.
