Currently, every script and module that requires configuration values has a snippet of code that reads /etc/koha.conf. This means that a particular operation might cause a script to read /etc/koha.conf several times. That can't be good for performance. In addition, since the snippet of code is nearly identical everywhere, it's just begging to be put into a separate function. To that end, I've written C4::Config module, which reads /etc/koha.conf (or a file of your choice, or the file pointed to by the $KOHA_CONF environment variable), and caches the results. If people think this is a Good Idea, just let me know where to send the code. Along those same lines, a lot of functions use $dbh = C4Connect; to get a handle to the Koha database. The way C4Connect is implemented, it creates a new handle each time. So if 'search.pl' finds ten results, it'll open 14 connections to the database. This seems wasteful, especially if the web server and database server aren't the same machine. So if C4::Config is well received, I'll also fix C4Connect to cache the database handle and return the same one each time, if it can. Finally, a number of scripts need to know which branches or item types exist. But I'll venture that after the initial setup, neither of these changes more than once every few months. It seems rather silly to have a script query the database for these values, when they could be cached locally. Hence, it would make sense to save this information in a Perl module on the web server, so that scripts don't have to query the database each time. And run a cron job once an hour to regenerate this module from the information in the database. Thoughts? Is this sensible, or am I full of it? -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com Real Programmers use "cat > a.out".
Hence, it would make sense to save this information in a Perl module on the web server, so that scripts don't have to query the database each time. And run a cron job once an hour to regenerate this module from the information in the database.
This sounds interesting, but what effects might it have on platform independence? Nick Rosasco
Andrew Arensburger wrote:
Currently, every script and module that requires configuration values has a snippet of code that reads /etc/koha.conf. This means that a particular operation might cause a script to read /etc/koha.conf several times. That can't be good for performance. In addition, since the snippet of code is nearly identical everywhere, it's just begging to be put into a separate function. To that end, I've written C4::Config module, which reads /etc/koha.conf (or a file of your choice, or the file pointed to by the $KOHA_CONF environment variable), and caches the results. If people think this is a Good Idea, just let me know where to send the code.
Along those same lines, a lot of functions use $dbh = C4Connect; to get a handle to the Koha database. The way C4Connect is implemented, it creates a new handle each time. So if 'search.pl' finds ten results, it'll open 14 connections to the database. This seems wasteful, especially if the web server and database server aren't the same machine.
I already saw and points this problem a few months ago, but due to lack of time... Note in the new MARC API, EVERY function is called with $dbh being 1st parameter... (if one is not : then it's a bug, or it doesn't use db access at all)
So if C4::Config is well received, I'll also fix C4Connect to cache the database handle and return the same one each time, if it can. Finally, a number of scripts need to know which branches or item types exist. But I'll venture that after the initial setup, neither of these changes more than once every few months. It seems rather silly to have a script query the database for these values, when they could be cached locally. Hence, it would make sense to save this information in a Perl module on the web server, so that scripts don't have to query the database each time. And run a cron job once an hour to regenerate this module from the information in the database. Thoughts? Is this sensible, or am I full of it?
I agree. And I can add another table : the "stopword", which is HEAVILY used when you add a marc record. Another idea : would it be possible to change $dbh to transform it in a "koha param object container" having : * the db handle * /etc/koha.conf parameters * some "static" tables the best would be to be still able to have $dbh->prepare or $dbh->do, but to add $dbh->param() to get koha parameter of $dbh->stopwords to get hash or array of stopwords... If we could, then we hadn't to modify all koha API. -- Paul
On Mon, Sep 30, 2002 at 10:57:18AM +0200, paul POULAIN wrote:
Andrew Arensburger wrote:
So if C4::Config is well received, I'll also fix C4Connect to cache the database handle and return the same one each time, if it can. Finally, a number of scripts need to know which branches or item types exist. But I'll venture that after the initial setup, neither of these changes more than once every few months. It seems rather silly to have a script query the database for these values, when they could be cached locally. Hence, it would make sense to save this information in a Perl module on the web server, so that scripts don't have to query the database each time. And run a cron job once an hour to regenerate this module from the information in the database. Thoughts? Is this sensible, or am I full of it?
I agree. And I can add another table : the "stopword", which is HEAVILY used when you add a marc record. Another idea : would it be possible to change $dbh to transform it in a "koha param object container" having : * the db handle * /etc/koha.conf parameters * some "static" tables the best would be to be still able to have $dbh->prepare or $dbh->do, but to add $dbh->param() to get koha parameter of $dbh->stopwords to get hash or array of stopwords...
If we could, then we hadn't to modify all koha API.
If I understand correctly, you're suggesting a "Context" object, which contains all of the information that you need to perform some operation. In addition to what you've listed above, I'd throw in the user's preferences (theme, home branch, printer, etc.), and perhaps the desired output type (HTML, CSV, curses, etc.). This has esthetic appeal, but I wonder if it's overkill. I believe that the typical script reads /etc/koha.conf, opens a handle to the database, then uses those values until it exits. It doesn't (or shouldn't) open any new database handles, or run a sub-query with a different configuration, or anything like that. That is, normally there will only be one Context object, and it will remain unchanged throughout the lifetime of the script. So why not just use a few global variables (or global access methods)? The only exception I can think of is in the case of a library system where the libraries are almost unified, but some are semi-independent for political or historical reasons. For example: when you search the umd.edu catalog, you get the option of searching either the Law Library catalog, or all other libraries at UMD. I don't know why this is so, but it appears that the Law department is at least somewhat separate from the other libraries. In Koha terms, you would do almost everything through koha.umd.edu (including authentication, list of branches, etc), except for Law catalog searches, which would go through koha.law.umd.edu. In this case, you might want one Context object for user login, and another for searching the Law library. How common is this sort of situation? Do we even want to worry about it? Or is there a better way to handle this sort of thing? If I seem to be arguing against myself, above, it's simply because I'm not sure what the Right Answer is. -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com "If you only have a nail, you tend to see every hammer as a problem." -- Larry Wall
participants (3)
-
Andrew Arensburger -
Nicholas S. Rosasco -
paul POULAIN