Stefan Jakobs: > > On Tuesday 14 December 2010 14:43:23 Wietse Venema wrote: > > Stefan: > > > A drawback is that this > > > solution is not as configurable/flexible as the other one. And it's still > > > the case that the first two values of a fetched tuple must be the > > > address and its corresponing cache timings (data). But I guess that is > > > acceptable. > > > > Do you really mean that the implementation is usable only for the > > Postfix verify(8) database format? > > Sorry, my describtion wasn't clear. > No, the implementation isn't bound to the verify(8) database format. The > dict_mysql_sequence() function will return any key-value pair, as demanded by > the interface. But the mysql HANDLER NEXT call will return a complete row of > the table as an array. And the first element of this array must be the key > and > the second element must be the value. So the implementation of > dict_mysql_sequence() expects the database to be in a specifc format, e.g > (key|data|...).
OK, that is not too restrictive, just a matter of documentation. > > Have you tested this with query and update activity while a sequence > > operation is in progress? That is required by the Postfix dict_cache > > implementation. > > Yes, I have tested that and it worked without problems. If you > are interested then I will send you the logs of that test. Yes, it would help when I want to run some tests (the results should be similar). One more question: what happens if a "first" sequence operation is requested before the last one is finished? Should the code maintain an internal flag that the "handler open" is still in effect, and do the "right" thing when another "first" sequence operation is requested? Wietse Wietse