[Koha-devel] DBIx::Class vs current Koha's DBI performance

[Chris Cormack]

* Clay Fouts (cfouts at liblime.com) wrote:
>    Do you have a roadmap/plan for the transition to TT? This process also
>    seems like a good time to start separating out the monolithic
>    "get_template_and_user" function. It would be very handy and allow for
>    more elegant design if we were able to specify the template just prior to
>    rendering it rather than at the very beginning.

Hi Clay

We have a summer of tech student who has lots of experience with machine
translation. The roadmap for 3.4 TT work looks like this

1/ Exact translation of the templates from HTML::Template::Pro to TT,
scripted and repeatable.

2/ Lots and lots of testing

3/ Call a template freeze

4/ Run the conversion a final time.

5/ Start accepting template patches again, but only TT ones.

6/ Maybe start changing things.

But the main aim is to get TT in there, so that we can start changing
things like get_template_and_user, caching rendered fragments etc. 

>    One method of breaking up the circularity that appears in many areas of
>    Koha is by splitting functions out in a MVC-style arrangement. If you're
>    finding yourself tempted to introduce a circularity in your data schema,
>    it's often the case that that relationship can be expressed through a View
>    or Controller class instead.

Yep, and if you come across one, patches to fix them would be
gratefully received, thats the kind of refactoring we should encourage.

>    Having worked with Catalyst, it's a fine framework, but it's cumbersome
>    and not worth porting existing code to. If writing an app from the ground
>    up it would be a consideration.

I agree.

Chris

>    Clay
> 
>    2010/11/4 Chris Cormack <chrisc at catalyst.net.nz>
> 
>      * Kyle Hall (kyle.m.hall at gmail.com) wrote:
>      >    How much work would it be to move Koha to the Catalyst framework?
>      >    Kyle
> 
>      Only a complete rewrite.
> 
>      The work we are doing with Plack and Starman will give us a persistent
>      environment, that will, in all likelihood outperform any framework
>      unless it was also running under Plack.
> 
>      Back to DBIx::Class, I have no plans to use it for anything other than
>      schema abstraction for 3.4. April 22 isn't far away.
>      However if someone sends in patches for a module that uses DBIx::Class
>      and we don't take a big performance hit, (and it passes QA and the rest
>      of the tests) it would go in.
> 
>      Small steps, we have a 6 month release, getting Template::Toolkit,
>      Schema abstraction, C4/Search fixes, all the RFC in is going to be
>      enough. Lets work on small manageable improvements. Anyone who wanted to
>      work on finding the circular object references we have, and breaking
>      them would move us a lot closer to being able to run the whole of Koha
>      under a persistent tool.
> 
>      Currently people are testing with the Opac, and circulation, with good
>      results.
> 
>      Chris
>      >    http://www.kylehall.info
>      >    Mill Run Technology Solutions ( http://millruntech.com )
>      >    Crawford County Federated Library System ( http://www.ccfls.org )
>      >    Meadville Public Library ( http://www.meadvillelibrary.org )
>      >
>      >    On Wed, Oct 27, 2010 at 2:27 AM, Frederic Demians
>      <frederic at tamil.fr>
>      >    wrote:
>      >
>      >        My experience is that the startup overhead introduced by
>      DBIx::Class
>      >        is not sufficiently offset by its caching features in a CGI
>      >        environment. Running under Plack or something similar would
>      easily
>      >        recoup that overhead, of course.
>      >
>      >      Yes, this is the solution. We need in 2010 a persistent
>      environment to
>      >      execute Koha in: an execution environment, in which they are
>      >      application-level, session and page objects Memcaching everything
>      isn't
>      >      the solution.
>      >      --
>      >      Frederic
>      >
>      >      _______________________________________________
>      >      Koha-devel mailing list
>      >      Koha-devel at lists.koha-community.org
>      >    
>       http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> 
>      > _______________________________________________
>      > 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/
> 
>      --
>      Chris Cormack
>      Catalyst IT Ltd.
>      +64 4 803 2238
>      PO Box 11-053, Manners St, Wellington 6142, New Zealand
>      -----BEGIN PGP SIGNATURE-----
>      Version: GnuPG v1.4.10 (GNU/Linux)
> 
>      iEYEARECAAYFAkzTCNkACgkQZgbcHEvgMLMERACfaf1UurKAXRc+yZ+t4ie5n2dg
>      FPwAnRfenGuZCDlW8j2SK4Z0Ydy04v2v
>      =odUu
>      -----END PGP SIGNATURE-----
> 
>      _______________________________________________
>      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/

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20101105/d6de65a4/attachment.pgp>