Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Am 24.03.12 15:35, schrieb Robin Sheat: > Op 25-03-12 03:19, Marc Balmer schreef: >> No, it does not rewrite any reports. If users enter SQL somewhere, I >> assume they enter proper SQL for their DB server. Which leads to a > > OK, so it doesn't address this (quite minor) problem. It would mean parsing the SQL and rewriting it. I think - besides that is hard to do right - it would be way over the top. > >> I am considering to write a set of compatability functions for >> PostgreSQL that add the most used MySQL functions, but I don't know yet >> how to mimick server crashes and data loss that can occur in MySQL :> > > I'd have a look through the reports library on the wiki and see what > functions are in use. There won't be many. ExtractValue is the only > common one I know of, dunno if the pgsql equivalent is syntactically the > same. > >> Id'd say it becomes clear once look at the bug and code. DBQ stands for > > The bug doesn't count once the code is in master. The code isn't clear > because the documentation doesn't say anything about what it does, so > there's no context. So no, not clear at all for someone trying to figure > out what a particular call's purpose is. > > One particular example: > > =head2 ifNull > > $value = $dbq->ifNull($a, $b); > > Returns $a if not null, else return $b > > =cut > > This is actually wrong if you take it at face value out of context. It > returns a string that does that in the database. That should be noted. > But more importantly, there's no documentation saying anything about the > purpose of all this. Don't assume people can work it out from the code > because that's a waste of their time. Make it explicit. You're creating > an API that can be produced by perldoc. (This said, it's nice to see > perldoc comments in there at all - so much of the code doesn't have > anything.) > > As an aside, the lack of placeholder use in these functions is a little > scary. I know that's hard to do, but it'd be worth trying. > >> Data Base Query and ir produces database specific SQL. It must only be >> used where there is no other way to get the job done (i.e. don't use it >> to produce DB specific code when there is a standard SQL way of doing so >> or when there is corresponding functionality in DBI). > > Then say this somewhere in the documentation. FWIW, there is some explanations on the wiki at wiki.koha-community.org/wiki/PostgreSQL. It is work in progress, so see it in that context. In the end, it will be documented, it's just that we don't know yet which idioms exactly need to go into DBQ (it will become more clear once we can install Koha on PostgreSQL and are able to actually test the real functionality). - mb ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Op 25-03-12 03:19, Marc Balmer schreef: > No, it does not rewrite any reports. If users enter SQL somewhere, I > assume they enter proper SQL for their DB server. Which leads to a OK, so it doesn't address this (quite minor) problem. > I am considering to write a set of compatability functions for > PostgreSQL that add the most used MySQL functions, but I don't know yet > how to mimick server crashes and data loss that can occur in MySQL :> I'd have a look through the reports library on the wiki and see what functions are in use. There won't be many. ExtractValue is the only common one I know of, dunno if the pgsql equivalent is syntactically the same. > Id'd say it becomes clear once look at the bug and code. DBQ stands for The bug doesn't count once the code is in master. The code isn't clear because the documentation doesn't say anything about what it does, so there's no context. So no, not clear at all for someone trying to figure out what a particular call's purpose is. One particular example: =head2 ifNull $value = $dbq->ifNull($a, $b); Returns $a if not null, else return $b =cut This is actually wrong if you take it at face value out of context. It returns a string that does that in the database. That should be noted. But more importantly, there's no documentation saying anything about the purpose of all this. Don't assume people can work it out from the code because that's a waste of their time. Make it explicit. You're creating an API that can be produced by perldoc. (This said, it's nice to see perldoc comments in there at all - so much of the code doesn't have anything.) As an aside, the lack of placeholder use in these functions is a little scary. I know that's hard to do, but it'd be worth trying. > Data Base Query and ir produces database specific SQL. It must only be > used where there is no other way to get the job done (i.e. don't use it > to produce DB specific code when there is a standard SQL way of doing so > or when there is corresponding functionality in DBI). Then say this somewhere in the documentation. Robin. signature.asc Description: OpenPGP digital signature ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Am 24.03.12 15:07, schrieb Robin Sheat: > Op 25-03-12 03:01, Marc Balmer schreef: >> We adress this problem with the DBQ module, which exists to produce >> database specific SQL code when there is no standard way to express sth >> and when there is no way to get it through DBI. See the example we >> bundled with the path in bug 7365. > > I'm not going to read the code because it's 3am, but does it rewrite the > reports people enter or something? That seems dangerous unless done > super-carefully. No, it does not rewrite any reports. If users enter SQL somewhere, I assume they enter proper SQL for their DB server. Which leads to a small problem: Reports that people share should be flagged as MySQL only, PostgreSQL only, or portable. Well, at least once Koha runs on sth different than MySQL... I am considering to write a set of compatability functions for PostgreSQL that add the most used MySQL functions, but I don't know yet how to mimick server crashes and data loss that can occur in MySQL :> > > (Also, the DBQ stuff seems to be quite underdocumented. It doesn't even > say what it is!) Id'd say it becomes clear once look at the bug and code. DBQ stands for Data Base Query and ir produces database specific SQL. It must only be used where there is no other way to get the job done (i.e. don't use it to produce DB specific code when there is a standard SQL way of doing so or when there is corresponding functionality in DBI). - mb ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Op 25-03-12 03:01, Marc Balmer schreef: > We adress this problem with the DBQ module, which exists to produce > database specific SQL code when there is no standard way to express sth > and when there is no way to get it through DBI. See the example we > bundled with the path in bug 7365. I'm not going to read the code because it's 3am, but does it rewrite the reports people enter or something? That seems dangerous unless done super-carefully. (Also, the DBQ stuff seems to be quite underdocumented. It doesn't even say what it is!) Robin. signature.asc Description: OpenPGP digital signature ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Am 24.03.12 14:44, schrieb Robin Sheat: > Op 25-03-12 02:28, Jared Camins-Esakov schreef: >> MySQL supports ExtractValue too. Is there something special in the >> Postgres functionality that makes a difference for the end user? > > Actually, this is something worth considering when supporting multiple > databases: some reports may require a different syntax/function names. > While it wouldn't be a blocker or anything like that, it's worth keeping > in mind. We adress this problem with the DBQ module, which exists to produce database specific SQL code when there is no standard way to express sth and when there is no way to get it through DBI. See the example we bundled with the path in bug 7365. - mb ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Op 25-03-12 02:28, Jared Camins-Esakov schreef: > MySQL supports ExtractValue too. Is there something special in the > Postgres functionality that makes a difference for the end user? Actually, this is something worth considering when supporting multiple databases: some reports may require a different syntax/function names. While it wouldn't be a blocker or anything like that, it's worth keeping in mind. Robin. signature.asc Description: OpenPGP digital signature ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Tomas, > >> Are there any specific features of PostgreSQL that would lead to a > > >> beneficial new feature for library patrons? I know there is plenty of > > >> literature on it's merits over MySQL, but how do those translate to > > >> something that the users of Koha can benefit from? > > > > > > Yes, of course. > > > > Such as? > > ExtractValue for custom reports? > MySQL supports ExtractValue too. Is there something special in the Postgres functionality that makes a difference for the end user? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcam...@cpbibliography.com (web) http://www.cpbibliography.com/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
El 23/03/2012 22:22, "Christopher Nighswonger" escribió: > > On Fri, Mar 23, 2012 at 5:38 PM, Marc Balmer wrote: > > Am 23.03.12 21:39, schrieb Ian Walls: > >> Marc, > > ... > > > > >> Are there any specific features of PostgreSQL that would lead to a > >> beneficial new feature for library patrons? I know there is plenty of > >> literature on it's merits over MySQL, but how do those translate to > >> something that the users of Koha can benefit from? > > > > Yes, of course. > > Such as? ExtractValue for custom reports? To+ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] is there a full koha anonymized test database available to squash bugs against?
On 2012-03-22, at 2:22 AM, Liz Rea wrote: > I have one that is a combo of sample data and MARC21 data - you can get it at > https://github.com/wizzyrea/Scripts-and-Things/blob/master/kohadev-withbibs.sql.gz > (do note, it's possible the rules in there are not quite sane or not defined > in a way that makes sense. Step through the administration when you get it > imported.) > > And just the marc data: > https://github.com/wizzyrea/Scripts-and-Things/blob/master/MARC21.mrc > > I've got an ongoing project to make a collection of sample data, and rule > sets that developers can choose and import at install time, but they are not > ready quite yet. :) > > Liz Rea oooh, nice one Liz :) perhaps we could work towards using some standardized data-sets for testing Koha we could have a set of UNIMARC, USMARC-MARC21 and NORMARC bibs, patrons, and a basically configured Koha database) does anyone else have any UNIMARC, NORMARC (and other *MARC) data-sets they could contribute? PGP.sig Description: This is a digitally signed message part ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] Fwd: [Koha-zebra] Apache issue
Begin forwarded message: > From: luis diaz > Date: 24 March 2012 12:41:41 AM NZDT > To: koha-ze...@lists.koha-community.org > Subject: [Koha-zebra] Apache issue > > Hello > > I have a rhel6 server (Linux el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 > x86_64 x86_64 x86_64 GNU/Linux) > Red Hat Enterprise Linux Server release 6.2 (Santiago) > > and I have install koha version 3.06.04 > So, all the steps have been done without errors, inclusive the compilation of > all the perl packages. > But, I have an error with the apache configuration, the web pages do not > appear, and I have this error: > > Internal Server Error > > The server encountered an internal error or misconfiguration and was unable > to complete your request. > > Please contact the server administrator, and inform them of the time the > error occurred, and anything you might have done that may have caused the > error. > > More information about this error may be available in the server error log. > > Additionally, a 500 Internal Server Error error was encountered while trying > to use an ErrorDocument to handle the request > > > I don't know what to look, the error_log do not helps here: > > [Fri Mar 23 06:43:20 2012] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Fri Mar 23 06:43:20 2012] [notice] Digest: generating secret for digest > authentication ... > [Fri Mar 23 06:43:20 2012] [notice] Digest: done > [Fri Mar 23 06:43:20 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 > mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured -- > resuming normal operations > [Fri Mar 23 07:36:37 2012] [notice] caught SIGTERM, shutting down > [Fri Mar 23 07:36:38 2012] [notice] SELinux policy enabled; httpd running as > context unconfined_u:system_r:httpd_t:s0 > [Fri Mar 23 07:36:38 2012] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Fri Mar 23 07:36:38 2012] [notice] Digest: generating secret for digest > authentication ... > [Fri Mar 23 07:36:38 2012] [notice] Digest: done > [Fri Mar 23 07:36:38 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 > mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured -- > resuming normal operations > The specidif koha error log is empty: > > koha]# tail -200f /var/log/koha/koha-error_log > > Maybe I must disable this: > > SELinux policy enabled? > > Hope some one can help here. > > Thanks a lot in advance > > > PGP.sig Description: This is a digitally signed message part ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
