Am 06.09.2013 12:08, schrieb Paul J Stevens: > On 09/06/2013 11:38 AM, Reindl Harald wrote: >> Hi Paul >> >> please let us know if you think this part in HEAD should >> work finally for testings and verify > > I'm running it on my dog-food installation without any problems. > Thunderbird really likes CONDSTORE.
hopefully other clients too :-) i dream all the time from a test-software simulating all sorts of clients and there behavior of the server responses and cry out if something unexpected happens but given that "Apple Mail" on two machines with the same patchlevel last year did not behave identical because these fools ship different binaries depending on the hardware generations this will never happen in case of the given mail it was a newsletter where i managed by accident a single dot in a line: one Mac stopped at this line with display the message, the other one not and since the dot was in the plaintext-alternate part the HTML one never appeared even not in the source code of the message that's the things we struggle with on the client side kaing verify whatever a really funny task :-) >> it happened twice to me that i built HEAD instead 3.1-tree by >> my own stupidity on the testserver and some chnages where done >> to the users-table and a view others but not finally and 3.2/HEAD >> was not happy with the result > > I really don't see how the upgrades can lead to dbmail being 'not > happy'. Unless you manually applied changes that conflict with the > migrations. OK, maybe i saw the warnings in one of the builds which are always there in case migration takes in action and the crashing was another issue in whatever snapshot i used by accident >> maybe because i have at least one own column "client_idnr" >> which i need to maintain my domain-mapping with a seperate >> table because my backends and scripts are domain-centric > > The current migrations add a few columns, but none of those collide with > 'client_idnr'. wonderful! > As a general advise, I would put such custom fields in an additional > table with a key-restraint: > > create table user_metadata ( > client_idnr bigint not null, > user_idnr bigint references dbmail_users (user_idnr) on delete > cascade on update cascade > ); > > > that way, you don't need to touch the core tables. oh no - behavior of 16019 lines PHP code with 550 KB depends on this and given that the code also adding and removing domains from the Barracuda spamfirewall via API bette rnot refactor :-) > I haven't looked at your schema, but some ideas: > > the current auto-migrations all use dbmail_ as table prefix. They really > should be dependent on the prefix set in dbmail.conf, but the migrations > are defined compile-time, not run-time. This could be alleviated by > supporting a --with-dbmail-table-prefix=... configure switch. good idea - on the other hand why compile-time? > Auto-migrations are *not* about validating the active schema. I really > don't care about your schema, I just care about functionality. Doing > validation would require a complete new framework for studying the > current schema (maybe translating it into a neutral non-sql form) and > comparing the result with a similar internal requirements config. > > A serious project with limited benefits, imo. forget it, that easily ends in a frustrating full-time job given it needs to support MySQL/PostgreSQL/Oracle/SQlite > Any auto-migration schema I add is small and fast. Stuff that would > require massive changes like we saw in 2_2-3_0 is never going to happen > 'automatically' good to know!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
