2014-09-11 13:29 GMT+02:00 Kyle Hall <kyle.m.hall@gmail.com>:
Can you see how this gives no advantage, but simply wraps the useful code in another layer of abstraction? There simply is no advantage to doing this. In the long run this type of thinking will make things more complicated and more error prone than they need to be.
The advantage is to share responsabilities, which is already a lot.
I don't understand your comment.
Not important, I just repeated myself: the functional job should not be done under the Koha::Schema::Result. It should only contain DB relationships without any intelligence on what happen above.
Instead of all this code we simply need to add one method to Result::Borrower. Here is the gist of it:
sub is_debarred { my ( $self ) = @_; return $self->debarred_date() > dt_from_string(); }
Think about all the overhead and complexity that is removed by this variation.
I don't understand where is the complexity. We need Koha::Module packages. We cannot put all our code into Koha::Schema::Result::Module. Why everyone is afraid of abstraction layers?
We *don't* need Koha::Module packages for everything! My point is that DBIC provides us with an abstraction layer already! Wrapping a DBIC class in another class provides no advantage and just obfuscates our code, increases hardware requirements, and leaves more room to introduce bugs. If we are just going to use DBIC to avoid writing direct sql queries, we should be using something like Fey instead.
Give me examples please: Which "modules" don't need specific packages? IMO, these ones should have their own modules: Order, Supplier, Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget, Fund, Patron.
We are a collective of developers with many different styles and opinions.
I completely agree with that :) That fact is that DBIC has been pushed into Koha 1 year ago and we don't have any plan. I tried several times and my patches have just been rejected. We never had this discussion (I mean a real/constructive discussion), nobody gives examples. I really would like someone shows me what he has in mind, like I did for Koha::Acquisition::[Order|Bookseller].
We often have very different approaches to how we implement new features. If we go down this path of wrapping DBIC in another abstraction layer, we simply continue down this patch of having many different bespoke implementations. If we use dbic as our abstraction layer, we remove much of that issue.
I we reach an agreement, we can do what we want. I hope some of you will be in Cordoba in 3 weeks! :)