Pat Eyler wrote:
Let's make first a dichotomy: database subsystem, other parts of the Koha system. Do you have any description of the database objects? I suppose it's a relational database with tables etc. Which are the tables, fields, field definitions? Are there other database objects the Koha system uses? Views? Procedures? How are they named? Does koha.mysql give the answer?
Yes, we use MySQL to handle the RDBMS. There aren't yet good documents on the database design. We aren't yet using views, stored procedures, or similar DB functionality.
we aren't using views/stored proc because mySQL doesn't handle them :-) I think that's the best reason :-)
Next there must be an interface (Naming of database objects constitutes part of this interface) between database and the other parts of the system? How is this designed and implemented? ODBC? If Koha is written in Perl and HTML, what is the communication mechanism with database?
You could consider Koha to use three tiers:
presentation (HTML generated from perl and HTML::Template) business logic (Perl and DBI) database (MySQL)
you can divide the business logic in 2 subparts : - .pl scripts that builds pages & call .pm for DB stuff - .pm in C4 directory that are used for all DB access (except for admin scripts : i did those script when i begun my involvement in Koha, and had missed the .pm theory)
We can also describe the deployment of subsystems and components according to machines (clients, servers). Does everything happen on one machine? DBMS on one machine, Apache and Perl on another? Are there any client components? Is Koha browser independent?
Koha proper runs on a single server (there's no reason you couldn't split this out though -- again one of the 2.2 goals is to make this easier). The only client component is a web browser. We've tried to stay browser independant, but there is currently a bit of javascript on some pages which limits us a little bit -- I don't think most libraries would be running the borwsers that don't play well with javascript.
* Apache & Perl on differents servers, i don't know if it's possible. If you need high scalability, you can always have X front end servers (apache/perl), accessing 1 mySQL server (for data consistency), and use dns round-robin on front-ends. * Javascript is used in MARC editor, and not "a little". This is a "must have". -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)