DBIC discussion overview

From Koha Wiki

Jump to: navigation, search
Koha > Technical > Development


DBIx::Class discussion overview

The discussion has been launched on the [mailing list].

This page will try to list and summarize the different points of view.

Context: Currently, we have 2 package directories: C4 (legacy) and Koha (the new one, should be OO only). We need to define what is the most adapted to migrate all the current code from C4 to Koha.

The Koha community needs to reach a consensus on the following questions.


1 - Where should we put the code logic?

a) Koha::Schema::Result::*

ex: Koha::Schema::Result::Borrower::is_debarred

  • take full advantage of DIBC
  • less complicated

b) Koha::*

ex: Koha::Borrower::is_debarred

  • more consistent
  • represent "things", not tables (1+ tables for 1 class).
  • scripts don't need to know or care how the data is stored (eg serialised objects in cache, redis etc)

2 - Should we allow find and searches in pl files?

a) Yes

  • easier to code
  • fixes provided faster

b) No

  • could be unit tested
  • easier to maintain
  • easier to reuse

3 - How should we manage ResultSet?

I dont understand this question, the Koha:: modules will deal with the db (or cache) and if using the DB will deal with the ResultSet

a) into Koha::Schema::ResultSet::*

b) into Koha::*::Set

4 - Does Koha::* class should extend Koha::Schema::Result::*

a) Yes

b) No

  • No, it should use it, where it needs to. To deal with the db, but some Koha objects don't need to touch the db directly.

5 - Does Koha::* class should extend Class::Accessor?

a) Yes

  • already used into Koha

b) No

6 - Have a common class Koha::Object and Koha::Object::Set

a) Yes

  • reuse some common stuffs

b) No

  • poor design
  • why create heavy objects when we just need light ones?
  • why layer a db abstraction over a db abstraction?
Personal tools