Fyi, I have added a second commit to the mongodb branch of my fork on github, which will enable mongo projections: https://github.com/21stcaveman/postfix/commits/mongodb
I have kept them separate in case it is chosen not to introduce projections for now. The reason I go back to projections, is that I see operations like concatenation all over when it comes to SQL setups with postfix. Even looking at postfix-admin docs, I can see the same: https://github.com/postfixadmin/postfixadmin/blob/master/DOCUMENTS/POSTFIX_CONF.txt I understand that it might not be good database design, but I'm not sure if we should limit users' choice when it comes to layout of the database. Also, without projections, the Mongo implementation would be incomplete compared to the SQL implementation. Regards Hamid Maadani June 24, 2022 5:49 PM, "Hamid Maadani" <ha...@dexo.tech> wrote: >> Excellent, note that this should count each attribute value as one result, >> whether from the same >> document, or multiple documents. > > Done. > >> 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)? > > Guess I forgot to include that patch the last time. But yes. for example, if > a mailing list is > formed like: > { "name": "d...@test.com", "active": 1, "createdAt": ISODate("<some_date>"), > "addresses": [ > "ha...@dexo.tech", "vik...@postfix.org" ] } > > then: > filter = { "name": "%s", "active": 1 } > return_attribute = addresses > > for key "d...@test.com" will return: > ha...@dexo.tech,vik...@postfix.org > > Regards > Hamid Maadani > > June 24, 2022 11:32 AM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote: > >> 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;.
