<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>>> I don't understand where is the complexity. We need Koha::Module<br>
>> packages. We cannot put all our code into<br>
>> Koha::Schema::Result::Module.<br>
>> Why everyone is afraid of abstraction layers?<br>
><br>
><br>
> We *don't* need Koha::Module packages for everything! My point is that DBIC<br>
> provides us with an abstraction layer already! Wrapping a DBIC class in<br>
> another class provides no advantage and just obfuscates our code, increases<br>
> hardware requirements, and leaves more room to introduce bugs. If we are<br>
> just going to use DBIC  to avoid writing direct sql queries, we should be<br>
> using something like Fey instead.<br>
<br>
</span>Give me examples please: Which "modules" don't need specific packages?<br>
IMO, these ones should have their own modules: Order, Supplier,<br>
Biblio, Item, Issue, Authorised value, Suggestion, Library, Budget,<br>
Fund, Patron.<br></blockquote><div><br></div><div>Why do you believe these need Koha modules? Each one of these already has an object with methods via DBIC. We can add more methods either for a given Library via Result::Branch, or for a collection of libraries via ResultSet::Branch</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> We are a collective of developers with many different styles and opinions.<br>
<br>
</span>I completely agree with that :)<br>
That fact is that DBIC has been pushed into Koha 1 year ago and we<br>
don't have any plan. I tried several times and my patches have just<br>
been rejected.<br>
We never had this discussion (I mean a real/constructive discussion),<br>
nobody gives examples.<br>
I really would like someone shows me what he has in mind, like I did<br>
for Koha::Acquisition::[Order|Bookseller].<br></blockquote><div><br></div><div>I'd really love to get a chance to write something that exemplifies this. So far the only bit has been Result::Item::effective_itemtype()</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> We often have very different approaches to how we implement new features. If<br>
> we go down this path of wrapping DBIC in another abstraction layer, we<br>
> simply continue down this patch of having many different bespoke<br>
> implementations. If we use dbic as our abstraction layer, we remove much of<br>
> that issue.<br>
<br>
</span>I we reach an agreement, we can do what we want.<br>
<br>
I hope some of you will be in Cordoba in 3 weeks! :)<br>
</blockquote></div><br></div><div class="gmail_extra">I wish I was going! Unfortunately, with a baby in the house I've made the decision not to attend this year. It was not an easy decision to make, and I'll miss getting to see everyone. I hope any discussions regarding these issues will continue to take place here and on #koha so I can participate!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Kyle</div></div>