Ok, back in town and back at it again.
Want to discuss the 'result_attribute' before I go ahead with the
implementation though.
It is kind of the same story as with 'filter' and 'search_key' attributes. If
we are to
return multiple fields, each of which might need a custom projection. So, We
would need to
have multiple result_attributes, and each one is either set to '1' (matching
exact field
in the document), or an optional JSON document for projection.
Consider this data set:
{ "first": "hamid", "last": "maadani", "domain": "dexo.tech", active: 1,
"other": "some other field 1"}
{ "first": "viktor", "last": "dukhovni", "domain": "postfix.org", active: 1,
"other": "some other field 2"}
{ "first": "wietse", "last": "venema", "domain": "postfix.org", active: 0,
"other": "some other field 3"}
Let's say I need mail path for all active users, as well as their last name.
The format
for mail path is 'first@domain/'. The filter would be simple:
{ "active": 1 }
We need to build this projection for the desired result:
{ "_id": 0, "last": 1, "mail_path": {"$$concat": ["$$first", "@", "$$domain",
"/"]} }
which would return:
maadani,ha...@dexo.tech/,dukhovni,vik...@postfix.org/
'result_attributes' would be need to be set to :
result_attributes = last, mail_path
and I guess the 'projection' attribute would need to be set to something like:
projection = 1, {"$$concat": ["$$first", "@", "$$domain", "/"]}
and we would need to build full projection from this. Now, if we needed full
name instead of lastname,
the projection attribute would need to become:
projection = {"$$concat": ["$$first", "$$last"]}, {"$$concat": ["$$first", "@",
"$$domain", "/"]}
or something similar to this.
Would it not be more beneficial/easier to leave the projection as a JSON object
and up to the user,
instead of having 'result_attribute'?
Regards
Hamid Maadani
June 18, 2022 6:59 PM, "Hamid Maadani" <ha...@dexo.tech> wrote:
>> but multi-connection thread pools and threads, ... all for a single
>> connection are way overkill.
>
> Fair enough. mongoc_client_t it is.
>
> Will update here when these changes are taken care of. Out of town at the
> moment.
>
> Regards
> Hamid Maadani
>
> June 18, 2022 6:04 PM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote:
>
>> On Sun, Jun 19, 2022 at 12:47:39AM +0000, Hamid Maadani wrote:
>>
>>> perhaps typically querying a single underlying "database" with
>>> different queries/results for each "table".
>>>
>>> Isn't that the case, when we configure postfix with mysql for example,
>>> and create different tables for virtual domains, virtual users and
>>> virtual aliases?
>>
>> Yes, a single database with multiple tables is common. So reusing
>> connections across tables makes some sense, but multi-connection
>> thread pools and threads, ... all for a single connection are
>> way overkill.
>>
>> IIRC the LDAP table code does attempt to share the same LDAP connection
>> for tables that differ essentially only in the query and result
>> attributes.
>>
>> At this stage, best to keep it simple and make the code correct first.
>> Optimisations (whether thread pools or connection sharing can come
>> later).
>>
>> --
>> Viktor.
