Koha Test Wiki MW Canasta on Koha Portainer

Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.

For the current Koha Wiki, visit https://wiki.koha-community.org .

DBIC discussion overview

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

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.

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?