If Chris was accurate in saying that there was active pursuit of postgres compatibility, then only the second option would make sense.
My own estimation is that pg-compatibility is so far from being implemented, for most code it almost doesn't matter. By that, I mean that the database representation and the entire DBI will likely be changed (e.g. DBIx::Class) "underneath" most of the work to make Koha's SQL queries compatible (before they are converted). But in these two cases, the kohastructure.sql file and updatedatabase.pl, I don't see any way around it. They would have to be compatible. Or at least, their being compatible would be better than there being a *different* updatedatabase file and a *different* kohastructure file. --Joe On Tue, Sep 8, 2009 at 11:06 AM, Zeno Tajoli <taj...@cilea.it> wrote: > Hi to all, > > as I said in the last IRC meeting, > http://stats.workbuffer.org/irclog/koha/2009-09-02#i_295862, > as CILEA we are working on mantain dcoumentation on Mysql tables, > indexeses and relations. > The work done until now is here: > http://wiki.koha.org/doku.php?id=en:development:dbschema > > The instrument used is Schema Spy, http://schemaspy.sourceforge.net/. > As I know is the better tool avaible for those works and open source. > > Well, to create a good documentation Schema Spy needs comments > INSIDE definion of Mysql tables. > > So the SQL command of the table 'action_logs' now is : > > CREATE TABLE `action_logs` ( > `action_id` int(11) NOT NULL auto_increment, > `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update > CURRENT_TIMESTAMP, > `user` int(11) NOT NULL default 0, > `module` text, > `action` text, > `object` int(11) default NULL, > `info` text, > PRIMARY KEY (`action_id`), > KEY (`timestamp`,`user`) > ) ENGINE=InnoDB DEFAULT CHARSET=utf8; > > For Schema Spy needs to be: > > CREATE TABLE `action_logs` ( > `action_id` int(10) NOT NULL default '0' COMMENT 'Action ID', > `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update > CURRENT_TIMESTAMP COMMENT 'Timestamp', > `user` int(10) default NULL COMMENT 'User', > `module` text COMMENT 'Module on which the action was performed', > `action` text COMMENT 'Action (e.g., ADD,MODIFY,RETURN, etc.)', > `object` int(11) default NULL, > `info` text COMMENT 'Info about the action performed', > PRIMARY KEY (`action_id`), > KEY `timestamp` (`timestamp`,`user`) > ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='[sys] Log of actions > performed on the system'; > > So Schema Spy need the command 'COMMENT' with useful information. > > So, the decision that we need to take: > > Do we insert the command 'COMMENT' in the basic definition SQL file, > the file installer/data/mysql/kohastructure.sql ? > Or do we insert the command 'COMMENT' in a specific file ? > > > With the first option is very clear how to document a new develop on > SQL, in the file installer/data/mysql/kohastructure.sql. > With the second option we have a more standard > installer/data/mysql/kohastructure.sql file [COMMENT is a command > specific of MySQL] > but it is easier to forget to document the new develop. > > I prefer the first option but there are differents opinion about it. > So, please, tell what do you prefer. > > Bye > > > > > > > > > Zeno Tajoli > CILEA - Segrate (MI) > tajoliAT_SPAM_no_prendiATcilea.it > (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @) > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha.org > http://lists.koha.org/mailman/listinfo/koha-devel >
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
