To mantain documentation on Mysql tables, indexess and relation

[tajoli-2]

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@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Joe Atzberger]

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 <tajoli@...> 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@...
http://lists.koha.org/mailman/listinfo/koha-devel

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[bob-318]

Hi,

My name is Bob and I'm having a problem with the
/etc/init.d/koha-zebra-daemon restart

it gives me this error

Restarting the Zebra Server
daemon: fatal: failed to find pid for koha-zebra-ctl.koha3: No such file
or directory


I'm unable to locate the missing pid file and want to know if/how to
kill the process and start a new one

I can currently do searches in opac so zebrasrv looks to be running
right - but i need the change i made to
etc/zebradb/marc_defs/marc21/biblios/record.abs
to be picked up

I'm using debian etch

I tried lsof|grep zebrasrv to find process number to kill it but each
time i try that it instantly reappears at new process number

I would appreciate advice on how to kill the current zebrasrv process
and how to start it up again properly.

Thanks
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[tajoli-2]

Hi to all,

I'm sorry for not attending IIRC meeting of 07-Oct-2009, but I was outside.
So, from last IIRC and now, the question is:

>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 ?

My preference is the first option, someone are agree, someone are not agree.
The real and big obstacles again first option is:
  -- Not all RDBMS support it o similar syntax
     It works only on MySQL, Postgresql, Oracle.
     It not works on Firebird, Sqlite, MS SQL
-- We want to use Class::DBI. Class::DBI doesn't support it

In fact the next release, 3.2, it will work only on MySQL and (not
very probably) on Postgresql with two
differect kohastructure.sql. No problem to have 'COMMENT' only on
MySQL version of kohastructure.sql

I don't know the plan for 3.4.
If Class::DBI will be used, CILEA will work to insert 'COMMENT' only
in installation with Mysql, starting from
an external file.

So. This is good for every one ?

I wait your answers.

Bye
Zeno

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@...
http://lists.koha.org/mailman/listinfo/koha-devel

[nengard]

I am for you adding the notes in the COMMENT in the basic SQL file -
so I too am for your first option.

Nicole

On Mon, Oct 12, 2009 at 7:08 AM, Zeno Tajoli <tajoli@...> wrote:

> Hi to all,
>
> I'm sorry for not attending IIRC meeting of 07-Oct-2009, but I was outside.
> So, from last IIRC and now, the question is:
>
>>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 ?
>
> My preference is the first option, someone are agree, someone are not agree.
> The real and big obstacles again first option is:
>  -- Not all RDBMS support it o similar syntax
>     It works only on MySQL, Postgresql, Oracle.
>     It not works on Firebird, Sqlite, MS SQL
> -- We want to use Class::DBI. Class::DBI doesn't support it
>
> In fact the next release, 3.2, it will work only on MySQL and (not
> very probably) on Postgresql with two
> differect kohastructure.sql. No problem to have 'COMMENT' only on
> MySQL version of kohastructure.sql
>
> I don't know the plan for 3.4.
> If Class::DBI will be used, CILEA will work to insert 'COMMENT' only
> in installation with Mysql, starting from
> an external file.
>
> So. This is good for every one ?
>
> I wait your answers.
>
> Bye
> Zeno
>
> 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@...
> http://lists.koha.org/mailman/listinfo/koha-devel
>

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Colin Campbell-5]

On 10/12/2009 12:08 PM, Zeno Tajoli wrote:
> Hi to all,

> My preference is the first option, someone are agree, someone are not agree.
> The real and big obstacles again first option is:
>    -- Not all RDBMS support it o similar syntax
>       It works only on MySQL, Postgresql, Oracle.
But not in compatible syntaxes. We are talking about adding another
mysqlism into the database structure.
(Admitted localised to kohastructure.sql)
> -- We want to use Class::DBI. Class::DBI doesn't support it
Actually Chris was talking, I believe, about using DBIx::Class not
Class::DBI. Using DBIx::Class does offer us more options in having a
better defined schema.

We probably need to review what our options are in the future for db
compatibility.

Colin

--
Colin Campbell
Software Engineer, PTFS Europe Limited
Content Management and Library Solutions
[phone] (phone)
[phone]  (mobile)
colin.campbell@...
skype: colin_campbell2

http://www.ptfs-europe.com
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[tajoli-2]

Hi to all,

> > My preference is the first option, someone are agree, someone are
> not agree.
> > The real and big obstacles again first option is:
> >    -- Not all RDBMS support it o similar syntax
> >       It works only on MySQL, Postgresql, Oracle.
>But not in compatible syntaxes. We are talking about adding another
>mysqlism into the database structure.
>(Admitted localised to kohastructure.sql)

I think that now kohastructure.sql is a SQL file for MySQL.
In fact the path is installer/data/MYSQL/kohastructure.sql
If we create support for Postgresql  in 3.2 we will create
installer/data/PGSQL/kohastructure.sql

And yes, we are speaking about DBIx::Class.
Also DBIx::Class doesn't support 'COMMENT'

>We probably need to review what our options are in the future for db
>compatibility.

Clearly this is connect with future for db compatibility.
But I can confirm that CILEA will work on a different solution if we use
DBIx::Class in 3.4

We don't need COMMENT in every DB definition for 3.2.

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@...
http://lists.koha.org/mailman/listinfo/koha-devel