<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 10, 2014 at 9:19 PM, Robin Sheat <span dir="ltr"><<a href="mailto:robin@catalyst.net.nz" target="_blank">robin@catalyst.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kyle Hall schreef op wo 10-09-2014 om 20:51 [-0400]:<br>
<span class=""><br>
<br>
> It's funny, I've been trying to think of an example search to justify<br>
> this and I can't really think of one where we can't use existing<br>
> Result relationships to get our data. Maybe find() and single() are<br>
> really all we need from pl files, but I don't think a hard and fast<br>
> rule against search() is a good idea.<br>
<br>
</span>We'd still be coupling to the data storage schema, which is bad. It's<br>
exactly the same logic that says not to have SQL in the .pl files.<br>
<span class=""><br></span></blockquote><div><br></div><div>I'm simply saying it doesn't seem that something like search( borrowernumber => $borrowernumber ) should be abstracted away.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> Result and ResultSet are part of the Koha namespace. I also feel that<br>
<br>
</span>Only in the sense that they have Koha:: in the name. They are an API to<br>
the database, and are generated directly from the database schema. They<br>
are not an API that is designed to provide logical access to whatever it<br>
is.<br>
<span class=""><br></span></blockquote><div><br></div><div>We can always re-engineer our Result and ResultSet's to use any theoretical future construct. We needn't use another layer of API's.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>  you aren't quite correct about how one modules need to know the<br>
> change a present the same interface. I can't count the number of times<br>
> I've added a new parameter to an existing subroutine and had to update<br>
> every function call in many perl files. Now that hashref's are more<br>
> common, it's become less of a problem but it's still a problem that<br>
> exists.<br>
<br>
</span>"It's been broken in the past" isn't a justification for "so we should<br>
keep it broken." As we go to a more OO and thought out method of writing<br>
things (again, especially with the Koha:: stuff), we are moving away<br>
from "here's a hashref with the fields from the biblio table" to "here's<br>
an object that represents a biblio, with accessors and modifiers." We<br>
want more of this, and less things going and talking to the database<br>
themselves.<br></blockquote><div><br></div><div>I agree. DBIC *provides* objects that represent a biblio with accessors and modifiers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I just don't think this is a entirely valid point. Remember, Result<br>
> and ResultSet methods are no different than methods anywhere else in<br>
> Koha and C4.<br>
<br>
</span>They are totally different. They are much closer to an abstraction of<br>
the database, compared to an abstraction of whatever it is the data is<br>
representing. And the code at the .pl level should be working with<br>
abstractions of data, e.g. "a reserve", or "a biblio with attached<br>
items", not "a set of hashrefs containing a biblio, a biblioitem, and<br>
the associated item records." This latter is what Result/ResultSet<br>
represent.<br></blockquote><div><br></div><div>Only if we don't take advantage of what DBIC is capable of. I agree, in the way we are using it now you are correct. That's why I've proposed what I have.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the ES code, I've been keeping this in mind. For example, I can go<br>
(from memory):<br>
<br>
my $it = Koha::Biblio->get_iterator;<br>
while (my $bib = $it->next) {<br>
   add_to_index($bib);<br>
}<br>
<br>
which means I don't have to care how they're stored. It also meant that<br>
it took very little work to refactor it to handle authorities, as<br>
everything had the same style of API. ResultSet stuff happened in the<br>
modules, but none of it was exposed to the script that was using those<br>
modules.<br>
<span class=""><br></span></blockquote><div><br></div><div>I don't see how this couldn't have been accomplished just as easily with DBIC. Biblios and authorities would also share the same DBIC methods.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> Exactly. If you look at my accounts rewrite you'll see I didn't try to<br>
> shoehorn everything into Result and ResultSet. I used a Koha module<br>
> that uses Results and ResultSets in a sane fashion.<br>
<br>
</span>And that's fine. Just not at the .pl level. The job of modules is to put<br>
a sensible abstraction between the storage layer and the user interface<br>
layer. As soon as UI related code can touch the storage layer, you're<br>
violating that principle and causing maintenance headaches for the next<br>
person who comes along.<br>
<div class="HOEnZb"><div class="h5">><br></div></div></blockquote><div><br></div><div>The UI isn't touching the storage layer, its touching an abstraction layer. I'm just not for the idea of abstracting our abstraction layer. I think we are in general agreement. I just disagree about hard and fast rules that could limit the real potential we have with DBIC.</div><div><br></div><div>Kyle</div></div></div></div>