<div dir="ltr"><div class="gmail_extra"><div>On Fri, Sep 12, 2014 at 3:43 AM, Jonathan Druart <span dir="ltr"><<a href="mailto:jonathan.druart@biblibre.com" target="_blank">jonathan.druart@biblibre.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>2014-09-12 3:31 GMT+02:00 David Cook <<a href="mailto:dcook@prosentient.com.au" target="_blank">dcook@prosentient.com.au</a>>:<br>
> That said, I think Colin and Kyle have good points about not wanting to<br>
> abstract the abstraction, as it does add overhead. DBIC can be slow. Plus,<br>
> the more layers, the more possible bugs.<br>
<br>
</span>We need to create a Koha API, a good and better API. For that the only<br>
way to do is to add Koha classes to wrap the DBIC ResultSet classes<br>
(note that we could extend it).<br></blockquote><div><br></div><div>This ^. That's the solution. If we extend the resultset class then we can retain all the DBIC methods and retain the ability to leverage all the strengths of DBIC. For example, let's say we want to carp/die if a particular key isn't passed to create(), or maybe we any delete to fail if there's still a row in table X that's related to it. All we need to do is use inheritance so we can test our conditions, then call the parent's create(), or delete() or whatever method.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I really don't think performance will be impacted here. The difference<br>
can be ignore.<br>
I disagree with the "more layers, more bugs" idea. An abstraction<br>
layer adds flexibility and a better overview.<br>
For instance, I think we should have a Koha::Record class. Biblio and<br>
Authority would be a Koha::Record.<br></blockquote><div><br></div><div>We can use multiple inheritance or Roles ( interfaces in OO terminology ) to achieve this. That way each Biblio and Authority share a common set of methods and can be used interchangeably in certain circumstances. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Do you think this new class adds more complexity? To me it adds<br>
consistence and the common code will be refactored in this class.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> But unless I'm missing something... DBIC can't give us a single "Biblio"<br>
> object that would contain data from "biblio" and "biblioitems" or<br>
> "deletedbiblio" and "deletedbiblioitems". We would need a "Koha" object.<br>
> Now... that's probably because of shortcomings with the schema, like Colin<br>
> mentioned. But... it seems to me that we're stuck with the schema for the<br>
> moment. Maybe "Biblio" isn't a good example, as it's a difficult one. Maybe<br>
> something simpler...<br></span></blockquote><div><br></div><div>DBIC can't give us a single record object technically, because of our schema ( the tables should be merged into one at this point in time ). However, we can solve this in two ways. We can either just write $biblio->biblioitem-><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px">marcxml and say it's not a big deal, or we can just add methods for each of the biblioitem methods so we can just treat them as one object:</span></div><div><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px">sub marcxml {</span></div><div><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px">    my $self = (@_);</span></div><div><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px">    return $self->biblioitem->marcxml;</span></div><div><span style="color:rgb(0,0,0);font-family:arial,geneva,helvetica,lucida,sans-serif;font-size:14px">} </span></div><div> </div><div>We can have a method that returns a MARC::Record, or perhaps we could even have our Result::Biblio inherit from MARC::Record, and our ResultSet::Biblio inherit from MARC::Batch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Koha has a lot of complex concepts. Because it offers a lot of modules<br>
and possibilities to the users. Koha has to work for every<br>
configuration across the world.<br>
Biblio won't be a special case. So there are not reason to cut the<br>
class in 2 groups: the simple and the complex.<br>
All lot will need their own modules, because we need to be flexible and logical.</blockquote><div><br></div><div>I absolutely agree. I think at the simplest we can use our Result and ResultSet classes, at the next level we can extend our Result and ResultSet classes, and at the far end of the spectrum we have fancy classes that don't map easily to the database but use DBIC objects to get things done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
> I'm skeptical but I'm intrigued.<br>
<br>
</span>Thanks to share your interest :)<br>
You managed to tell what I didn't.<br></blockquote><div><br></div><div>Agreed!</div><div><br></div><div>Kyle</div></div></div></div>