[Dovecot] dovecot 1.2: dict no longer really support DICT_ITERATE_FLAG_RECURSE
Hi,
In dovecot 1.1, I could use DICT_ITERATE_FLAG_RECURSE when iterating over a dict to retrieve all entries that start with a given prefix. This doesn't seem to work anymore in the new dict implementation in dovecot 1.2. Looking at the SQL queries actually generated, it seems as if dovecot 1.1 used to generate queries that use pattern matching (key LIKE "my/prefix/%") whereas dovecot 1.2 does not, so it's no wonder that it doesn't work in 1.2.
This probably has to do with the pattern matching for dict keys in the config file. It would be enough for my purposes at the moment -- i.e. getting the metadata plugin to work with dovecot 1.2 -- if recursion were only possible for the last of fields in the pattern.
Regards,
Bernhard
-- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Oct 9, 2008, at 6:15 PM, Bernhard Herzog wrote:
This probably has to do with the pattern matching for dict keys in
the config file. It would be enough for my purposes at the moment -- i.e.
getting the metadata plugin to work with dovecot 1.2 -- if recursion were only
possible for the last of fields in the pattern.
I remember thinking about this and I thought I did something similar.
What kind of dict keys/configuration do you need now?
On 09.10.2008, Timo Sirainen wrote:
On Oct 9, 2008, at 6:15 PM, Bernhard Herzog wrote:
This probably has to do with the pattern matching for dict keys in the config file. It would be enough for my purposes at the moment -- i.e. getting the metadata plugin to work with dovecot 1.2 -- if recursion were only possible for the last of fields in the pattern.
I remember thinking about this and I thought I did something similar. What kind of dict keys/configuration do you need now?
I currently use a configuration like this:
map { table = dict pattern = shared/$key value_field = value username_field = username fields { key = $key } }
There's a similar entry for a priv/$key pattern. This was the most obvious way of getting the metadata plugin to work with dovecot 1.2.
key contains the mailbox name followed by the annotation name. When doing a recursive iteration, the key only contains the mailbox name and thus the iteration returns all the annotations for a given mailbox. That's how it worked with dovecot 1.1 anyway.
The way the mailbox and annotation name are translated into a dict key is not ideal, but I'd prefer to get the annotations working with 1.2 before trying to improve this (e.g. so that the pattern could become somethng like shared/$mailbox/$key).
Bernhard
-- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
I did several fixes to dict iteration. Now it should work as I intended (which is also hopefully how you want to use it): http://hg.dovecot.org/dovecot-1.2/rev/72b7277aefb3
On 12.10.2008, Timo Sirainen wrote:
I did several fixes to dict iteration. Now it should work as I intended (which is also hopefully how you want to use it): http://hg.dovecot.org/dovecot-1.2/rev/72b7277aefb3
Thanks. The dict-sql code needed the attached change to build the correct order by clause. After that it worked fine.
Regards,
Bernhard
-- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Mon, 2008-10-13 at 18:25 +0200, Bernhard Herzog wrote:
On 12.10.2008, Timo Sirainen wrote:
I did several fixes to dict iteration. Now it should work as I intended (which is also hopefully how you want to use it): http://hg.dovecot.org/dovecot-1.2/rev/72b7277aefb3
Thanks. The dict-sql code needed the attached change to build the correct order by clause. After that it worked fine.
Committed, although I think that at least in some situations it adds some useless fields to the ORDER BY query. But I didn't bother fixing it yet since it doesn't break anything.
participants (2)
-
Bernhard Herzog
-
Timo Sirainen