[icinga-devel] [PATCH] modified database_templates

Hendrik Baecker andurin at process-zero.de
Sat May 23 11:35:18 CEST 2009


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

Hello Markus,

I'm on my way to test your patches and have some comments.

mareadmin schrieb:
>  module/idoutils/db/mysql2.sql | 1412 ++++++++++++++++++++++++++++++++++++++++

Example diff:

 CREATE TABLE IF NOT EXISTS `icinga_timeperiod_timeranges` (
- -  `timeperiod_timerange_id` int(11) NOT NULL auto_increment,
- -  `instance_id` smallint(6) NOT NULL default '0',
- -  `timeperiod_id` int(11) NOT NULL default '0',
- -  `day` smallint(6) NOT NULL default '0',
- -  `start_sec` int(11) NOT NULL default '0',
- -  `end_sec` int(11) NOT NULL default '0',
+  `timeperiod_timerange_id` INTEGER NOT NULL auto_increment,
+  `instance_id` INTEGER NOT NULL default '0',
+  `timeperiod_id` INTEGER NOT NULL default '0',
+  `day` INTEGER NOT NULL default '0',
+  `start_sec` INTEGER NOT NULL default '0',
+  `end_sec` INTEGER NOT NULL default '0',
   PRIMARY KEY  (`timeperiod_timerange_id`),
   UNIQUE KEY `instance_id` (`timeperiod_id`,`day`,`start_sec`,`end_sec`)

Just a question:
Why should it be better to use INTEGER instead of [small]int(x)?

- -) ENGINE=MyISAM  COMMENT='Timeperiod definitions';
+)   COMMENT='Timeperiod definitions';
There are some rumors in the net regarding the db engine type if you are
ISV or OEM.
IMHO the DB Admin has to decide about their license, not the guys behind
an OpenSource Project.
Any comments from the list? (Maybe without flaming ^^)

>  module/idoutils/db/pgsql.sql  | 1420 +++++++++++++++++++++++++++++++++++++++++
Ok - I'm starting to get in touch with Postgre SQL :(

ERROR:  Type »datetime« doesn't exist.

On a actual pgsql 8.4...

Workaround might be:
CREATE DOMAIN datetime as timestamp;

Wouldn't it be better to use "timestamp" instead of "datetime"?
If I'm right, datetime was already deprecated in 7.4.

I guess lines like this would be better:
...
queued_time timestamp NOT NULL default '1970-01-01 00:00:00',
...

Another problem exists with varchar(x) character set latin1...
This seems to be totaly wrong for psql, so I dropped the
"character set latin1"
completely.

Third problem: "double"
If I'm right "double" should be a "double precision" even in SQL standard?
Comments?

- -
Hendrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoXw1YACgkQlI0PwfxLQjniAwCfdW8w7UUcpj0Bv/6W3EjWaiVz
mHsAn2yPMBdlMLXsYd0Eg4G75KaExCdx
=0eRx
-----END PGP SIGNATURE-----




More information about the icinga-devel mailing list