Agreed! The next step I think is to move ( add ) caching from C4::Context into Koha::Config::SysPrefs thus removing all dependency on those C4::Context subs. After that we begin replacing the use of C4::Context->preference with Koha::Config::SysPrefs. Does that make sense? I wonder if we can implement Koha::Cache for syspref caching now. I'm not up to date with it's state. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jun 10, 2015 at 10:23 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
I think the natural next step is to just remove set_preference and preference from C4::Context.
2015-06-10 11:17 GMT-03:00 Fridolin SOMERS <fridolin.somers@biblibre.com>:
I noticed the use of Koha::Config::SysPrefs in C4::Context introduces circual dependences :( C4::Context > Koha::Config::SysPrefs > Koha::Database > C4::Context
You confirme ?
Maybe we should create a new module C4::Config with all methods not directly linked to the context.
Regards
Le 04/06/2015 19:13, Tomas Cohen Arazi a écrit :
I've just pushed bug 13967 [1]. It introduces a new package (Koha::Config::SysPrefs) that heavily relies on DBIx::Class to deal with the required CRUD for system preferences.
It should be no surprise that the first widespread use of DBIx on Koha's codebase raises problems. Widespread means every call to anything is using it :-D.
The point: it noticeably broke lots of our t/db_dependent/ tests. A first guess would point to the package itself. But such doesn't seem to be the case. It is highlighting an underlaying problem in how we deal with the DB: the errors are related to nested transactions taking place, so I would point to our (abuse?) of $dbh->{AutoCommit} = 0 on the tests.
Actually, if you pick any db_dependent test that is currently failing on master and set the AutoCommit = 1 you will notice the tests work as expected (with the side effect of altering the DB of course).
So, this is a call for all of you, whenever you find some time, to try to figure what's going on and possible solutions to this. I ain't no DBIx expert and will be doing my best but really need your help.
Before someone says it: reverting the commits will put us back to the previous state, of course. But it will just hide the problem for a while.
[1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13967
_______________________________________________ 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/
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.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/
-- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
_______________________________________________ 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/