Send Koha-devel mailing list submissions to
        koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
        koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
        koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

   1. Re: Koha and DBIC (Kyle Hall)
   2. Re: Koha and DBIC (Colin Campbell)
   3. Re: Koha and DBIC (Marcel de Rooy)
   4. Re: Koha and DBIC (Mark Tompsett)
   5. Re: Koha and DBIC (Colin Campbell)
   6. Re: Koha and DBIC (Chris Cormack)


----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Sep 2014 06:40:09 -0400
From: Kyle Hall <kyle.m.hall@gmail.com>
To: Jonathan Druart <jonathan.druart@biblibre.com>,     Kyle Hall
        <kyle.m.hall@gmail.com>,        Koha Devel
        <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID:
        <CACpVHfyZnF9jpWKW5hGcmXtG4eZFf+YpCzkJGiqEwhm11XkoEA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Chris, I'm a bit lost here. The idea behind Koha::Object is that we have a
common base class from which to derive Koha::Biblio, Koha::Serial and so
forth. That is, this class would be used as the base for classes that have
a simple 1 to 1 table mapping to encapsulate DBIC while maintaining a
consistent set of methods across our many classes. ObjectSet would give us
set iterators, set operations, and be a better place to have methods that
return a set ( e.g. Koha::Issue::Set::GetOverdues would return a collection
of overdue checkouts ).

I'm not sure why you disagree with this idea. Could you expand a bit?

Kyle


> -1 for DBIx::Class calls in the .pl
> -1 for Koha::Object and Koha::Object::Set
> +1 for proper objects like Koha::Biblio, Koha::Account, Koha::Serial etc
>
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/3b5fc3d8/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 17 Sep 2014 11:49:23 +0100
From: Colin Campbell <colin.campbell@ptfs-europe.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID: <20140917104923.GA7912@zazou.cscnet.co.uk>
Content-Type: text/plain; charset=us-ascii

A Koha::Object sounds like extremely poor design. What kind of object is
a Koha::Object, what are its properties, when we say a Koha::Biblio isa
Koha::Object what does that mean? In practice what meaningful properties
it has it inherits from Koha::Schema::Result::Biblio which is liable to
be a better representation than the vaguer Onject.

In practice I've recently written some scripts which in first version
used some abstractions built around dbic ResultSets, As I added to them
I stripped out out the abstractions and used the dbic result sets as I
found this generated cleaner, more straightforward code.

Colin

--
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell@ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com


------------------------------

Message: 3
Date: Wed, 17 Sep 2014 12:40:51 +0000
From: Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>
To: Koha Devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID:
        <809BE39CD64BFD4EB9036172EBCCFA31423D7E05@S-MAIL-1B.rijksmuseum.intra>
Content-Type: text/plain; charset="iso-8859-1"

> I would say: Leave all storage related actions in Koha::Schema. KohaRow does not make sense to me.
> Furthermore, define the objects that actually have 'real' business logic and put that in some Koha::Object.

Just to add to the confusion ;) When I wrote "some Koha::Object" here, I was not literally suggesting Koha::Object, I was thinking of something like Koha::Biblio or Koha::Patron etc.
I would not suggest to add such an object for every table in Koha. We should clearly define which objects(!) we really need, having sufficient business logic etc. to justify an interface to DBIx.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/036e8ce9/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/036e8ce9/attachment-0001.txt>

------------------------------

Message: 4
Date: Wed, 17 Sep 2014 08:50:37 -0400
From: "Mark Tompsett" <mtompset@hotmail.com>
To: "Marcel de Rooy" <M.de.Rooy@rijksmuseum.nl>
Cc: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID: <BLU172-DS21D031DE305CA383185011C6B60@phx.gbl>
Content-Type: text/plain; charset="utf-8"

Greetings,

> Just to add to the confusion ;)
> When I wrote "some Koha::Object" here,
> I was not literally suggesting Koha::Object,
> I was thinking of something like Koha::Biblio or Koha::Patron etc.
That?s what I understood. So physically, we may have the tables we currently have accessed via DBIC, but the Koha::Biblio object would blend DBIC objects related to Biblios and Items. Right? This would mean that Koha::Biblio would provide whatever methods regardless of the backend structure.
GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140917/34f28f56/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 17 Sep 2014 14:49:34 +0100
From: Colin Campbell <colin.campbell@ptfs-europe.com>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID: <20140917134934.GA10248@zazou.cscnet.co.uk>
Content-Type: text/plain; charset=utf-8

On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote:
> Greetings,
>
> > Just to add to the confusion ;)
> > When I wrote "some Koha::Object" here,
> > I was not literally suggesting Koha::Object,
> > I was thinking of something like Koha::Biblio or Koha::Patron etc.
> That?s what I understood. So physically, we may have the tables we currently have accessed via DBIC, but the Koha::Biblio object would blend DBIC objects related to Biblios and Items. Right? This would mean that Koha::Biblio would provide whatever methods regardless of the backend structure.

Trouble is it sidesteps fixing the schema. The interplay between biblio
and biblioitems will remain a problem for maintenance in future. There
is already special code added to link the classes because their
relationship is not maintained by the database. Special cases tend to
grow over time and spawn more special cases.

C.

--
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell@ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com


------------------------------

Message: 6
Date: Thu, 18 Sep 2014 04:07:55 +1200
From: Chris Cormack <chrisc@catalyst.net.nz>
To: Colin Campbell <colin.campbell@ptfs-europe.com>,
        koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Koha and DBIC
Message-ID: <3901e549-a890-4824-ba8c-6277e7078f42@email.android.com>
Content-Type: text/plain; charset=UTF-8



On 18 September 2014 1:49:34 am NZST, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
>On Wed, Sep 17, 2014 at 08:50:37AM -0400, Mark Tompsett wrote:
>> Greetings,
>>
>> > Just to add to the confusion ;)
>> > When I wrote "some Koha::Object" here,
>> > I was not literally suggesting Koha::Object,
>> > I was thinking of something like Koha::Biblio or Koha::Patron etc.
>> That?s what I understood. So physically, we may have the tables we
>currently have accessed via DBIC, but the Koha::Biblio object would
>blend DBIC objects related to Biblios and Items. Right? This would mean
>that Koha::Biblio would provide whatever methods regardless of the
>backend structure.
>
>Trouble is it sidesteps fixing the schema. The interplay between biblio
>and biblioitems will remain a problem for maintenance in future. There
>is already special code added to link the classes because their
>relationship is not maintained by the database. Special cases tend to
>grow over time and spawn more special cases.
>

It's not an either/or proposition, having Koha::Biblio doesn't mean you can't fix the schema too. It just means all the business logic for dealing with it is in that module/object. Instead of strewn about in scripts all over the place.

Chris




>C.
>
>--
>Colin Campbell
>Chief Software Engineer,
>PTFS Europe Limited
>Content Management and Library Solutions
>+44 (0) 800 756 6803 (phone)
>+44 (0) 7759 633626  (mobile)
>colin.campbell@ptfs-europe.com
>skype: colin_campbell2
>
>http://www.ptfs-europe.com
>_______________________________________________
>Koha-devel mailing list
>Koha-devel@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/

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


------------------------------

_______________________________________________
Koha-devel mailing list
Koha-devel@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/

End of Koha-devel Digest, Vol 106, Issue 23
*******************************************