[Koha-bugs] [Bug 8798] Add the use of DBIx::Class

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8798

--- Comment #72 from Kyle M Hall <kyle at bywatersolutions.com> ---
> [1] Once DBIC support is pushed, along with at least one other patch that
> uses it, we promote the existence of it vigorous, with the aim of
> encouraging folks to use it for new functionality even *before* KohaCon.  I
> agree that seminars there would be a good idea, too.

That sounds great to me!

> I think it would be a reasonable goal to get to the point where, once the
> cycle for 3.16 starts, DBIC is required for any new code that interacts with
> the database.  That can't be a requirement for 3.14, of course, but we can
> certainly encourage it.

I for one, will be writing all future patches the involve new scripts and subs
with DBIC from this point on.

> [2] I agree that we should make a concerted effort to switch existing code
> over to DBIC, but with a *very* strong caveat: I am disinclined to push
> patches that refactor code to use DBIC that are not backed up by unit tests
> first.  There will be some trickiness in writing such tests, of course,
> since switching functionality to DBIC also means restructuring the API, but
> I have very little tolerance for user-visible regressions in the name of
> architectural improvements, no matter how important.

I agree with unit testable-ness for functions, but what about scripts? One of
the great reasons to have DBIC is we can just use find() or single() to grab a
borrower in the script, rather than calling C4::Members::GetMember. Script mods
should of course have a full and thorough test plan, but I can't imagine them
being unit testable, right?

> However, one question that has to be answered first: who has time to commit
> to systematically refactoring existing code?  An answer to that would inform
> future planning.

I for one will absolutely commit to refactoring existing code! For smaller
modules I could probably submit one a week or more ( considering smaller
modules have fewer subs and often fewer callers ). Larger modules with subs
called often will probably need to be refactored on a sub by sub basis.

-- 
You are receiving this mail because:
You are watching all bug changes.