On Sat, Jun 18, 2022 at 02:45:26AM +0000, Hamid Maadani wrote:
> 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.
The client pool model could be justified, If you have a strong
understanding of how a client pool would work in a process with
potentially multiple open Postfix tables, perhaps typically querying a
single underlying "database" with different queries/results for each
"table".
Postfix processes are single-threaded, so serialise all the queries, and
if the database connection is reusable, and the pool is small, it could
work well.
Basically you want a "pool" of one connection per logical database
reguardless of the query filter or result attributes. With ideally
some reuse of that connection until idle long enough to drop it and
start a new one.
> Question about the result_attributes, how should multi-columned
> multiple results be returned?
Comma-separate everything. Whether from different rows, or different
columns. The only time this is relevant in Postfix is email address
lists.
> 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
It can only return a single string. So the above.
> or:
>
> hamid,blah
> wietse,viktor
This makes no sense. There are no structured result sets, just
single values or or comma-separated lists of email addreses.
Don't forget to support expansion_limit (typically 1 if used),
which would result in an error if more than one result would
need to be output (comma-separated). Unlike LDAP, there's
no recursion (no columns that are query URIs, triggering
recursion) so no need for a recursion limit.
--
Viktor.
