koha with better support for postgresql
Hi all, at this time how to improve support for koha to use postgresql, someone could explain that you can do to make fully functional koha with postgresql.I see that postgresql offers many features than can koha use managed to improve its performance. I like to explore the possibility of starting to develop the necessary code for koha to make a complete and functional use of all PostgreSQL features, with the help of experienced developers. Thank you, Ricardo
This isn't going to happen any time soon, if ever. It is, in my opinion, a waste of time to try to convert all the existing SQL statements and structure to be both mysql and PG-compatible, leading to a lot of duplication in almost every C4 subroutine. In particular, such effort could be more fruitfully applied to OO mapping and/or a DBIx::Class abstraction layer. That moves the codebase away from a specific DB implementation and towards something truly useful. --Joe 2009/12/1 ricardo mendoza <koha.spanish@gmail.com>
Hi all, at this time how to improve support for koha to use postgresql, someone could explain that you can do to make fully functional koha with postgresql.I see that postgresql offers many features than can koha use managed to improve its performance. I like to explore the possibility of starting to develop the necessary code for koha to make a complete and functional use of all PostgreSQL features, with the help of experienced developers.
Thank you, Ricardo
2009/12/3 Joe Atzberger <ohiocore@gmail.com>:
This isn't going to happen any time soon, if ever. It is, in my opinion, a waste of time to try to convert all the existing SQL statements and structure to be both mysql and PG-compatible, leading to a lot of duplication in almost every C4 subroutine. In particular, such effort could be more fruitfully applied to OO mapping and/or a DBIx::Class abstraction layer. That moves the codebase away from a specific DB implementation and towards something truly useful.
And that is indeed the plan, for 3.4. I have started on preliminary work for this, and it is going well. But yes database abstraction is a key goal for 3.4.0. I have successfully created a schema using DBIx::Class and the exisitng mysql database, and then created a postgres database using that schema. Worked fine. At the moment tho, I am doing testing on the 500 or so changes that were pushed last night for the 3.2.0 release. After the 3.2.0 release the DBIx::Class work in progress branch will start being worked on again. Chris
Chris, is good to hear this, for a long time I thought that koha never be able to give full support to postgresql, but I see that this is the way to get started. I am reviewing the code of 3.0.4, I want to make some contribution to koha, but I'm not a professional programmer so I have to start with small things. Ricardo,
2009/12/3 Joe Atzberger <ohiocore@gmail.com>:
This isn't going to happen any time soon, if ever. It is, in my opinion, a waste of time to try to convert all the existing SQL statements and structure to be both mysql and PG-compatible, leading to a lot of duplication in almost every C4 subroutine. In particular, such effort could be more fruitfully applied to OO mapping and/or a DBIx::Class abstraction layer. That moves the codebase away from a specific DB implementation and towards something truly useful.
And that is indeed the plan, for 3.4. I have started on preliminary work for this, and it is going well. But yes database abstraction is a key goal for 3.4.0. I have successfully created a schema using DBIx::Class and the exisitng mysql database, and then created a postgres database using that schema. Worked fine. At the moment tho, I am doing testing on the 500 or so changes that were pushed last night for the 3.2.0 release. After the 3.2.0 release the DBIx::Class work in progress branch will st Chris
What you mean Joe, is that it's much better to work with a layer of abstraction, regardless of the database used. Ricardo,
On Wed, Dec 2, 2009 at 3:00 PM, ricardo mendoza <koha.spanish@gmail.com>wrote:
What you mean Joe, is that it's much better to work with a layer of abstraction, regardless of the database used.
Yes, that's right. So it is better to move in that direction instead of trying to convert one particular form of SQL to another parallel alternative form of SQL (and then have to maintain them both... and still not have the OO/DBIx functionality). Chris' work is encouraging. ORM classes are definitely a different way of thinking about data though. The mapping is its own little ecosystem, and will require the structure to be maintained and updated (much like kohastructure.sql and updatedatabase). One great thing though, is that it combines with caching very naturally (caching an object, not just a DB row). --joe
Joe Atzberger wrote:
Chris' work is encouraging. ORM classes are definitely a different way of thinking about data though. The mapping is its own little ecosystem, and will require the structure to be maintained and updated (much like kohastructure.sql and updatedatabase). One great thing though, is that it combines with caching very naturally (caching an object, not just a DB row).
Perhaps a move towards Koha objects in perl could accompany this change, i.e. data model objects that present Koha constructs like Patron, Catalogue, Item, etc. Having used an ORM before, I think it is important to monitor the performance of the auto generated SQL, keep some metrics and optimise once the concepts are functioning. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Prohibition was better better than no liquor at all. -- Kin Hubbard
On 02/12/09 21:13, Rick Welykochy wrote:
Joe Atzberger wrote:
Chris' work is encouraging. ORM classes are definitely a different way of thinking about data though. The mapping is its own little ecosystem, and will require the structure to be maintained and updated (much like kohastructure.sql and updatedatabase). One great thing though, is that it combines with caching very naturally (caching an object, not just a DB row).
Perhaps a move towards Koha objects in perl could accompany this change, i.e. data model objects that present Koha constructs like Patron, Catalogue, Item, etc. I think this is a way we need to go, and hopefully it will make it easier for people to contribute new features in future. At the moment some of the routines in the libraries are huge and full of side effects for the unwary.
Having used an ORM before, I think it is important to monitor the performance of the auto generated SQL, keep some metrics and optimise once the concepts are functioning. It's very important, I've been down that road as well.
Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
You are right Colin, that way many people who do not have much programming
experience can make a contribution, not expecting to find that the code was mostly koha perl, my basic rudiments are programming in python, so for now they work in things that are much more according to my capacities to develop koha code. for now I have to resign and has translated some documentation and some designing koha themes, not bad to start.but it is very encouraging for me to hear that someone is working to better use postgresql in koha
Just an article about MySQL, and a reason to think about PostgreSQL: http://ostatic.com/blog/the-state-of-postgresql-not-so-easy-to-kil Some trends: http://www.google.com/trends?q=PostgreSQL%2C+mysql
participants (6)
-
Chris Cormack -
Colin Campbell -
Joe Atzberger -
Pablo A. Bianchi -
ricardo mendoza -
Rick Welykochy