<div dir="ltr"><div class="gmail_extra"><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"><div dir="ltr"><div>First question to be asked: why are we adopting an ORM?</div><div><br></div><div>If we are using it to abstract the DB engine selection (i.e. making Koha usable with Postgres instead of only MySQL) I'm sure we are wasting our time.</div><div>What's the point of rewriting the whole thing to just move away from an enterprise grade DB engine to another? Is it worth the trouble? I'm glad that using an ORM also serves that purpose, but...</div><div><br></div></div></blockquote><div><br></div><div>In the past if not now, there has been concerns about the future of MySQL. I think there has been a strong interest in enabling Koha to use Postgres at the very least.</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"><div dir="ltr"><div></div>I think our project is complex enough to benefit from strictly sticking to design patterns, such as the repository pattern; in which the ORM takes care of persistence and nothing more, and we build our business logic on top of that. On that subject, I fully agree with Robin, that we shouldn't rely on hooking the ORM to solve any business logic issue: we need to have our own abstraction layer with a proper API we maintain and unit test (mocked tests, and let integration tests deal with the ORM interaction). Hooking the ORM mixes layers, businesses and problems. That's why it is so hard to write some tests for Koha.</div></blockquote><div><br></div><div>I can totally agree with this, except I don't see where we are using any design patterns with Koha. I we need to retain the pattern of Objects and Object Sets. But we already have those though DBIC! In the end we could easily yank out DBIC and replace it with something else so long as it provides the same methods ( create, update, delete, find, search, etc ).</div><div><br></div><div>I am troubled by the idea that we should wrap all our dbic classes in yet more classes. Every example I've seen of this has more code by a factor of almost 10. I don't know if Koha is so complex that it requires a repository pattern.</div><div><br></div><div>Look at this example: <a href="http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31607&action=diff#a/Koha/Schema/ResultSet/Reserve.pm_sec1">http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31607&action=diff#a/Koha/Schema/ResultSet/Reserve.pm_sec1</a></div><div><br></div><div>How much more difficult will this be for developers, and how much more overhead will it require if we wrap our objects in more objects? We'd have to fetch the Row objects, wrap them in KohaRow objects, wrap those in a KohaRowSet, and return them. Certainly, but far more complicated.</div><div><br></div><div>That being said, if the majority agree, than I will be the first to jump aboard. However, there have definitely been others who are reticent  as well.</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"><div dir="ltr"><div><div><br></div><div>Also, our ERD needs some tweaking, to aid maintenance, code simplicity and to support an OO design [1]. For instance, a biblio should definitely have its table, and if biblioitems breaks the design, then we should just merge those tables. I wouldn't implement any hack on the code to preserve that discussed structure. I'd rather spend the time fixing it.<br></div></div></div></blockquote><div><br></div><div>I totally agree. The biblio and biblioitems tables need to be merged. Finding a volunteer will be the hard part!</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"><div dir="ltr"><div><div><div><br></div><div>So at that level, we should implement the repository pattern, with the following goals:</div><div>- Consistent API, independent of the DB model (people use our API, no need to know how we built our DB structure).</div></div></div></div></blockquote><div><br></div><div>Is this so other software can make use of Koha's functions and methods?</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"><div dir="ltr"><div><div><div>- Separation of concerns between layers (easier to code, easier to test, etc)</div></div></div></div></blockquote><div><br></div><div>I will concede that unit testing would be much easier if we could instantiate objects and object sets without using the database. It *is* trivial to create Result objects without touching the db, but ResultSets are another matter. However, it seems like it may be possible: <a href="http://modernperlbooks.com/mt/2011/05/testing-dbix-models-without-the-database.html">http://modernperlbooks.com/mt/2011/05/testing-dbix-models-without-the-database.html</a></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"><div dir="ltr"><div><div><div>- Let the ORM take care of DB stuff and use the spare time to talk about cats and food. [2]</div></div></div></div></blockquote><div><br></div><div>Don't forget about dogs! We've got plenty of dog lovers in out community ; )</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"><div dir="ltr"><div><div><div><br></div></div><div>I'd also like to have a RESTful layer for that API, that should be straightforward to maintain: endpoint routing, authorization layer, call to the right method, output. It is outside the scope of this thread, but a better separation of concerns might make it easier to achieve in a short term. We could the gradually move away from our .pl mess, that contains lots of business logic that doesn't get tested.</div></div></div></blockquote><div><br></div><div>This I completely agree with. I think all outside systems should interact with Koha though a well designed restful interface. I'm hoping to get started on this soon. Jesse Weaver has already written some great code I can use as a start.</div><div><br></div><div>Kyle</div></div></div></div>