DBMail 2.2.10 second release candidate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

I've just uploaded the second candidate for 2.2.10

Changes since 2.2.10-rc1:
- - cleanup the mysql schema definition
- - treat the deliver_to field as a string type in all
queries to
accomodate postgresql-8.3

download:
http://www.dbmail.org/download/2.2/dbmail-2.2.10-rc2.
tar.gz

full changelog:
http://git.dbmail.eu/?p=paul/dbmail;a=shortlog;h=v2.
2.10-rc2

debian/etch:
deb http://debian.nfgd.net/
debian stable main


happy testing,

- --
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFH26E68iITvBH4zTERAvVDAJj2rR93qFMHTZVBAQ3FTDrKWpYjAJ4m
jxMx
cp62xhqiMM25+bYvucRWiA==
=5Vzh
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Late question i know, but...

What about the cleanup in the mysql scheme definition? What
does that mean
for existing installations? Do we have to alter the tables
and if so which
one. Im asking because there is nothing mentioned within
upgrading install
or changelog within the distribution of 2.2.10. is there a
plan to
distribute a alter mysql script too? Im asking because what
happens when in
a future release you add/change features and has only the
"new" scheme in
mind forgetting the existing schemes? Inconsistency by
accident? Know what I
mean?

So?

Regards

Simon

-----Ursprüngliche Nachricht-----
Von: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] Im Auftrag
von Paul J Stevens
Gesendet: Samstag, 15. März 2008 11:13
An: DBMail mailinglist; DBMAIL Developers Mailinglist
Betreff: [Dbmail] DBMail 2.2.10 second release candidate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

I've just uploaded the second candidate for 2.2.10

Changes since 2.2.10-rc1:
- - cleanup the mysql schema definition
- - treat the deliver_to field as a string type in all
queries to
accomodate postgresql-8.3

download:
http://www.dbmail.org/download/2.2/dbmail-2.2.10-rc2.
tar.gz

full changelog:
http://git.dbmail.eu/?p=paul/dbmail;a=shortlog;h=v2.
2.10-rc2

debian/etch:
deb http://debian.nfgd.net/
debian stable main


happy testing,

- --
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFH26E68iITvBH4zTERAvVDAJj2rR93qFMHTZVBAQ3FTDrKWpYjAJ4m
jxMx
cp62xhqiMM25+bYvucRWiA==
=5Vzh
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Simon Lange wrote:
> Late question i know, but...
> 
> What about the cleanup in the mysql scheme definition?
What does that mean
> for existing installations? Do we have to alter the
tables and if so which
> one. Im asking because there is nothing mentioned
within upgrading install
> or changelog within the distribution of 2.2.10. is
there a plan to
> distribute a alter mysql script too? Im asking because
what happens when in
> a future release you add/change features and has only
the "new" scheme in
> mind forgetting the existing schemes? Inconsistency by
accident? Know what I
> mean?

It doesn't mean anything for existing installations. I do
*not* intent to
construct an alter table script. It only affects users of
not-yet-existing Rails
applications talking to the dbmail-mysql database directly.
It does not and will
not affect functionality of dbmail utilities or daemons.

The mysql cleanup mainly affected the width specification on
integer type
columns. Those width specifications do not affect storage,
but only provide
hints for displaying the column. Rails uses those hints to
deduce the intented
datatype: tinyint(1) is assumed to be a boolean, tinyint(3)
a normal 8bit
integer. A totally braindead approach imo, but there was no
downside for me to
accomodate an otherwise completely reasonable request.

The other change was setting the UNSIGNED keyword on all
integer type columns.
Since dbmail will already never insert negative values it
doesn't really matter
much for now. Mysql users who have UNSIGNED set on those
columns will see the
maximum value increase by 100%. But that will only affect
truly massive
installations, and those will/should have the manpower and
budget to hire a
mysql dba who can tweak the schema to fit their needs.



-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Okay, that wiped out any doubts.  thanks. I
just wanted to be sure about
this. ;)

Regards

Simon

-----Ursprüngliche Nachricht-----
Von: dbmail-bouncesdbmail.org [mailto:dbmail-bouncesdbmail.org] Im Auftrag
von Paul J Stevens
Gesendet: Donnerstag, 27. März 2008 09:14
An: DBMail mailinglist
Betreff: Re: AW: [Dbmail] DBMail 2.2.10 second release
candidate

Simon Lange wrote:
> Late question i know, but...
> 
> What about the cleanup in the mysql scheme definition?
What does that mean
> for existing installations? Do we have to alter the
tables and if so which
> one. Im asking because there is nothing mentioned
within upgrading install
> or changelog within the distribution of 2.2.10. is
there a plan to
> distribute a alter mysql script too? Im asking because
what happens when
in
> a future release you add/change features and has only
the "new" scheme in
> mind forgetting the existing schemes? Inconsistency by
accident? Know what
I
> mean?

It doesn't mean anything for existing installations. I do
*not* intent to
construct an alter table script. It only affects users of
not-yet-existing
Rails
applications talking to the dbmail-mysql database directly.
It does not and
will
not affect functionality of dbmail utilities or daemons.

The mysql cleanup mainly affected the width specification on
integer type
columns. Those width specifications do not affect storage,
but only provide
hints for displaying the column. Rails uses those hints to
deduce the
intented
datatype: tinyint(1) is assumed to be a boolean, tinyint(3)
a normal 8bit
integer. A totally braindead approach imo, but there was no
downside for me
to
accomodate an otherwise completely reasonable request.

The other change was setting the UNSIGNED keyword on all
integer type
columns.
Since dbmail will already never insert negative values it
doesn't really
matter
much for now. Mysql users who have UNSIGNED set on those
columns will see
the
maximum value increase by 100%. But that will only affect
truly massive
installations, and those will/should have the manpower and
budget to hire a
mysql dba who can tweak the schema to fit their needs.



-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail