[Koha-devel] Koha and DBIC

[Kyle Hall]

That is certainly a possibility. There are a few options with DBIC.
However, I ended up abandoning all of them for something custom with Libki.
We may have better results collectively than I did alone.

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )

On Wed, Sep 10, 2014 at 2:39 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>
wrote:

>  And what about deploying instead of kohastructure.sql ?
> Same for DBIx statements in updatedatabase..
> The current process was meant to be temporary (adding SQL in kohastructure
> and updatedatabase and having the RM update the DBIx scheme).
>
>  ------------------------------
> *Van:* koha-devel-bounces at lists.koha-community.org [
> koha-devel-bounces at lists.koha-community.org] namens David Cook [
> dcook at prosentient.com.au]
> *Verzonden:* woensdag 10 september 2014 8:26
> *Aan:* 'Kyle Hall'; 'Koha Devel'
> *Onderwerp:* Re: [Koha-devel] Koha and DBIC
>
>   Hi Kyle:
>
>
>
> Could you speak more to what a ResultSet method would be? From what I’ve
> seen Koha::Schema::* just has Results in it. Would we need to define custom
> ResultSets as well to get this kind of functionality?
>
>
>
> Overall, this sounds good to me. It would be nice to put more of the
> “database” code into one place, and have more of the “logic” or processing
> elsewhere. Like you say, more readable, testable, efficient.
>
>
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St, Ultimo, NSW 2007
>
>
>
> *From:* koha-devel-bounces at lists.koha-community.org [mailto:
> koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Kyle Hall
> *Sent:* Wednesday, 10 September 2014 3:22 AM
> *To:* Koha Devel
> *Subject:* [Koha-devel] Koha and DBIC
>
>
>
> As discussed in #koha, I think we are not using DBIC as well as we could.
> Right now we are only using it to replace hand written SQL queries. I would
> propose the following:
>
>
>
> 1) Allow find and simple searches in pl.
>
> 2) If a search is used more than once, it should be a ResultSet method
>
> 3) If a subroutine operates on a single table row, it should be a Result
> method
>
> 4) If a subroutine operates on a single table, it should be a ResultSet
> method
>
> 5) Any operation that works on tables linked by key constraints should
> take advantage of those DBIC relationships and also
>
>
>
> In this way we can do things like:
>
> $borrower->is_debarred
>
> or
>
> $borrower->has_overdues
>
> or
>
> @borrowers = $borrower->guarantees()
>
>
>
> Any search can be a method in the ResultSet such as
>
> $borrower->issue()->overdue_issues();
>
> or
>
> my @records_with_holds = $schema->resultset('Biblio')->with_holds()
>
>
>
> I think in the long run this will make or code far more readable,
> testable, and efficient.
>
>
>
> What do you think?
>
>
>
> Kyle
>
>
>
> http://www.kylehall.info
>
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
> Mill Run Technology Solutions ( http://millruntech.com )
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140910/92a07005/attachment.html>