The code is updated. Now:
- It accounts for the 'domain' parameter
- It requires a JSON formatted 'filter' parameter (no more search_key)
- 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
- It uses 'expansion_limit' attribute to control number of results being 
returned
- 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.
- advanced projections are commented out for now, and not supported.

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?

Regards
Hamid Maadani

June 21, 2022 10:23 PM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:

> On Wed, Jun 22, 2022 at 05:12:08AM +0000, Hamid Maadani wrote:
> 
>> Understood. Is there any prior code in postfix I can repurpose for array 
>> management to keep an
>> static list of mongoc_client_t objects (one per named dict)? Or should I 
>> write it within the
>> module?
>> trying to avoid creation and destruction of clients per lookup call, and 
>> keep a persistent
>> connection.
> 
> You don't need this. Postfix keepts tables open across queries, reusing
> the database connection for multiple queries. You'll have no static
> objects. All the objects you need should be referenced from the
> MongoDB-specific table (dictionary) structure.
> 
> Do not confuse "lookup" with "open". Tables stay open for the lifetime
> of the process, but connections can be restarted from time to time,
> after some time, or some number of queries, or when they're closed by
> the server, and a query detects that the server is gone (in that case
> the connection must be reopened and the query transparently retried,
> once).
> 
> --
> Viktor.

Reply via email to