During KohaCon12 hackfest, some of us had a discussion about Koha namespace organisation and content. The result was a wiki page: http://wiki.koha-community.org/wiki/Koha_Namespace_RFC I've investigated this organisation by writing some DBIx::Class & Moose packages. The results are great, a lot of code can be removed, and the code is safer. Note that the patches attached here are just a first draft, not requesting sign-off, just comments ! My feedback of this first try: * defining the schema has been easy, thanks to DBIx::Class documentation. Error messages are very clear and easy to understand for a newbie like me ! * investigating a little bit more, there are many tools/tricks that will make us save a lot of time/lines. Like caching (with DBIx::Class::Cursor::Cached), paging (see http://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/Class/Manual/Cookbook.pod#Paged_results, not used in this 1st POC), doing JOIN or finding relations between datas, or returning array of hashrefs (DBIx::Class::ResultClass::HashRefInflator) * cleaning categories.pl resulted in a code that is *much* smaller and readable than the previous one (something like 100 lines removed)
Created attachment 10473 [details] [review] DBIx::Class 1st step: the schema This DBIx::Class schema has been generated using perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:.Koha -e 'make_schema_at("temp::Schema", { debug => 1 }, [ "dbi:mysql:dbname=Koha","LOGIN", "PASSWORD" ])' After my 1st tests, I encountered the following problem DBIx::Class::Carp::__ANON__(): "might_have/has_one" must not be on columns with is_nullable set to true (temp::Schema::Result::Borrower/cardnumber). This might indicate an incorrect use of those relationship helpers instead of belongs_to. at /usr/share/perl5/DBIx/Class/Relationship/HasOne.pm line 96 by setting cardnumber to non-nullable I've switched the cardnumber to non-nullable in Borrower.pm
Created attachment 10474 [details] [review] Branches table management it's called Branch2.pm because I tried another organisation, then switched to this one, which is better I think
Created attachment 10475 [details] [review] Borrowers table management first draft, the interesting part is the testrelation.pl script that shows how to search a patron and access other informations from here What is important is the "prefetch" option in read. With it you'll LEFT join the prefetched table, thus improving performances You can also notice the cache duration of 2 seconds in borrower search. The idea is that, if this sub is called more than once on a given page, there will be only one SQL query.
Created attachment 10476 [details] [review] Branchrelation package, 1st draft unused in my tests I think, commiting it just in case
Created attachment 10477 [details] [review] Categories management This package is a POC to manage the Categories table. It contains : * Category.pm (DB, DataObject and BusinessLogic levels) * the Category.t test * categorie.pl DBIx::Classed * updating copyright * removing a lot of useless files * tabs replaced by 4 spaces, result in some minor changes * use [% IF condition %] in templates, to avoid some pl level hacks
Created attachment 10478 [details] [review] DBIx::Class Branch.pm, first try This package, and the test implement CRUD for Branches table. Very basic, but proves we can do many things in a few lines !
mmm... patches not in the historical order, sorry. I made patch 6 (Branch.pm first try) first, then Branches table management (Branch2.pm). To explain : I made some experiments on Branch.pm, then tried something else I called Branch2.pm Branch2.pm seems better, so if we decide to go this way, the original Branch.pm will be dropped and Branch2.pm renamed. As it's just a POC, that's not a big deal I think. In fact, the most important part is the testrelation.pl attached in "Borrowers table management" and Categories management, that include admin/categorie.pl rewritten
*** Bug 8798 has been marked as a duplicate of this bug. ***
4 years... Could this be closed?