On 20 March 2013 10:59, Damien Churchill damoxc@gmail.com wrote:
On 20 March 2013 10:54, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:40 +0000, Damien Churchill wrote:
On 20 March 2013 10:39, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
Would it not be just some bastardised version of dict-sql-settings?
I guess you could do that for now. The grand plans of how to put everything nicely together can wait. :)
For now I think I can get away with just tacking on uri arguments. Seems silly duplicating effort, although if you'd like me to give it a shot I'm happy to do so!
Hi,
I've pushed an initial copy of what I've got so far to bitbucket[0]. I'm in two minds currently about how to correctly handle returning the json object that the userdb/passdb backend expects. Currently the config file is copying mostly what dict-sql does:
connect = host=localhost:port=27017:db=mail
map { pattern = shared/passdb/$user collection = users username_field = email value_field = password
fields {
email = $user
}}
map { pattern = shared/userdb/$user collection = users username_field = email value_field = password
fields {
email = $user
}
values {
home = /home/vmail
uid = 5000
gid = 5000
}}
value_field isn't currently used at all, and the values map just provides some default values that will be replaced if they exist in the returned document.
The part I'm wondering is how to allow the object you end returning as flexible as what is currently possible with the sql passdb/userdb queries. May have to ultimately bite the bullet and accept that it won't be. Primarily it would be good to be able to concat strings with fields returned for building the quota rule or something similar. Just wondered what your thoughts were on this?
[0] https://bitbucket.org/damoxc/dovecot-2.2-mongodb/commits/0dee37209ff9f4b2f84...