Understood. This is great, appreciate the guidance. I'll work on implementing it this way and update this thread once the code is pushed.
Regards Hamid Maadani June 15, 2022 3:40 PM, "Viktor Dukhovni" <postfix-us...@dukhovni.org> wrote: > On Wed, Jun 15, 2022 at 10:12:57PM +0000, Hamid Maadani wrote: > >> Let's say I have a database called 'mail' in my MongoDB cluster, and there >> is a collection (table) named 'mailbox' inside of it. >> Each object in this collection holds a mailbox, and also includes it's >> aliases (real world example from my mail server): >> >> { >> "_id" : ObjectId(REDACTED), >> "username" : "ha...@dexo.tech", >> "password" : "REDACTED", >> "name" : "Hamid Maadani", >> "maildir" : "ha...@dexo.tech/", >> "quota" : REDACTED, >> "local_part" : "hamid", >> "domain" : "dexo.tech", >> "created" : ISODate("2016-11-07T21:07:21.000Z"), >> "modified" : ISODate("2017-05-02T22:10:00.000Z"), >> "active" : 1, >> "alias" : [ >> { >> "address" : "ab...@dexo.tech", >> "created" : ISODate("2016-11-07T21:04:16.000Z"), >> "modified" : ISODate("2016-11-07T21:04:16.000Z"), >> "active" : 1 >> }, >> { >> "address" : "hostmas...@dexo.tech", >> "created" : ISODate("2016-11-07T21:04:16.000Z"), >> "modified" : ISODate("2016-11-07T21:04:16.000Z"), >> "active" : 1 >> } >> ] >> }, >> >> { >> "_id" : ObjectId(REDACTED), >> "username" : "ad...@dexo.tech", >> "password" : "REDACTED", >> "name" : "Site Admin", >> "maildir" : "ad...@dexo.tech/", >> "quota" : REDACTED, >> "local_part" : "admin", >> "domain" : "dexo.tech", >> "created" : ISODate("2017-04-12T22:24:17.000Z"), >> "modified" : ISODate("2021-06-03T02:54:35.000Z"), >> "active" : 1 >> } > > See LDAP_README which talks about structurally similar use-cases. > >> Now, if I want to query for 'ha...@dexo.tech', or any of it's aliases, I >> would use >> this filter: >> filter = {"$$or": [{"username":"%s"}, {"alias.address": "%s"}], "active": 1} >> >> of course, this will return an entire JSON document. > > JSON documents will be fairly useless in Postfix, so there should always > be a projection, and its syntax should be more user-friendly by default, > so similar to "result_attribute" in LDAP, i.e. just a key to extract > from the JSON document, which should be either a string-valued scalar, > or a list of string values (which you would internally combine with > commas). > >> So I would use Mongo projections to >> limit it to just one key-value pair, in which case, the driver will only >> return the value: >> options = {"projection": {"_id": 0, "username": 1}} > > Using explicit "projections" should be an advanced feature, far better > to ask users to write: > > result_attribute = username > > (As a side question, Why is "_id" part of the "projection"???) > >> If I change the query to: >> filter = {"active": 1} >> >> and keep the same projection, it will return: >> {"username":"ha...@dexo.tech"} >> {"username":"ad...@dexo.tech"} >> >> from what you just described, the result should be returned as: >> ha...@dexo.tech,ad...@dexo.tech > > Yes. > >> That's the easy part. Question is, should I allow users to use the >> filter/options combination >> to search however they need? The reason I ask is, if someone uses this >> projection: >> {"projection": {"_id": 0, "username": 1, "name" : 1}} >> >> The results would be: >> {"username":"ha...@dexo.tech", "name":"hamid"} >> {"username":"ad...@dexo.tech", "name":"admin"} >> >> and I am unsure how to handle that. Limit it by requiring a key? > > Returning compound JSON objects should be an error. Only string and > list of string values should be supported. The result is obtained > by flattening all lists to a comma-separated string, and then combining > these (again comma-separated) across the returned JSON "documents". > >> Or just return the string representation of the JSON documents for the >> user to parse by 'jq' or similar utilities? > > No, because Postfix dictionaries are not for use in MongoDB query CLIs, > they are for the MTA to resolve email lists, transports, ... where > only scalar results and sometimes comma-separated lists are supported. > >> Would there be a use case for that (postmap -q ... | jq)? > > No. > >> I assume I should limit it by key, but want to run it by you guys first.. > > Read LDAP_README, virtual(5), aliases(5), transport(5), ... > > Note also that with e.g. LDAP there's also a way to specify an expansion > limit (e.g. 1), so that queries returning more than the expected number > of rows fail instead of returning garbage. > > So, also see ldap_table(5) for any additional table attributes (like > the previously mentioned "domain") that may apply. > > -- > Viktor.