Oracle nerfs MySQL, calls it MySQL classic, and charges $2, 000+ for features like InnoDB
http://www.mysql.com/products/ <http://www.mysql.com/products/>I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres? Kyle 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 )
It looks like I jumped the gun. This looks like it's about commercial support, not features, except where marked on the linked page. Kyle 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 Thu, Nov 4, 2010 at 6:14 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
http://www.mysql.com/products/
<http://www.mysql.com/products/>I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres?
Kyle
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 )
2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
It looks like I jumped the gun. This looks like it's about commercial support, not features, except where marked on the linked page.
That's not how I read it. It appears to me that your first assessment was correct. The first row of the chart shows support availability. Classic has no support available. The subsequent rows compare features. Clearly InnoDB is *not* checked in the MySQL Classic column. PG support is a goal for 3.4 IIRC, however, MariaDB (http://mariadb.org/) bills itself as a drop-in replacement for MySQL and developed and maintained by some of the folks who originally wrote MySQL. Kind Regards, Chris PS: This is yet *another* reason for the Koha community to refuse to allow the project to become vendor dominated/controlled. Let's be sure we are awake and smelling the coffee.
Hi, On Thu, Nov 4, 2010 at 8:31 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
It looks like I jumped the gun. This looks like it's about commercial support, not features, except where marked on the linked page.
That's not how I read it. It appears to me that your first assessment was correct.
The first row of the chart shows support availability. Classic has no support available.
The subsequent rows compare features. Clearly InnoDB is *not* checked in the MySQL Classic column.
InnoDB and the InnoDB plugin are still present in the MySQL "community edition" source download. I imagine that very few Koha users actually purchase "MySQL Classic" or another other version with a support contract from Oracle. (In fact, individual libraries *can't* purchase the Classic Edition, as it is only available to ISVs, OEMs, and VARs. The cheapest supported version that an ordinary user could purchase is Standard Edition). Nothing that Oracle does could cause InnoDB support to be, say, yanked from the Debian packages of MySQL. I don't think that Oracle price changes for MySQL support yesterday have any direct bearing on Koha users right now -- we can still get MySQL with InnoDB. Of course, Oracle can easily do things that would make MySQL very unattractive in the future, for example, by not releasing updates to the community edition, and I'm not defending their handling of their purchase of MySQL AB and Innobase Oy and their treatment of the MySQL project. We need to be prepared for all possibilities, and I will be porting my test database to MariaDB this weekend and seeing how that goes. However, I think we need to be clear on one point -- nothing changed yesterday that would prevent a new Koha library from being able to get MySQL with InnoDB. I can't speak about tomorrow. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Hi, 2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
http://www.mysql.com/products/ I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres?
In the short term, since MySQL and InnoDB are GPL, Oracle can't make the current code just disappear, but obviously the long-term prospects are not clear. In the medium term, adding support for MariaDB could help -- it gives us an upgrade to 5.1, is supposed to be a drop-in replacement for MySQL, and uses a replacement for InnoDB called XtraDB that looks like an improvement. On the other hand, packaging is a bit lacking at present. Drizzle also looks interesting, but it would require more work to remove the MySQLisms from Koha that Drizzle doesn't use. As far as Postgres support is concerned, I'm all for it. Of course, Chris' DBIx::Class RFC [1] is the current candidate for starting to get there. However, I would point out that a full implementation of DBIx::Class does not guarantee that we'll also get full Postgres support for 3.4; there is a lot of testing that would need to be done. [1] http://wiki.koha-community.org/wiki/RFC_for_using_DBIx_Class_in_Koha Regards, Galen -- Galen Charlton gmcharlt@gmail.com
I also think DBIx::Class is definitely the way to go. Here's a question: Is there any way to store the database schema in an intermediate format that can be used to create the database in MySQL, Postgres, or what-have-you? Perhaps there is a way to use DBIx::Class or another module to generate an agnostic schema from the current MySQL one? Caveat: This just popped into my head, I have not done any research of any kind. Kyle ] 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 Thu, Nov 4, 2010 at 8:34 AM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
http://www.mysql.com/products/ I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres?
In the short term, since MySQL and InnoDB are GPL, Oracle can't make the current code just disappear, but obviously the long-term prospects are not clear. In the medium term, adding support for MariaDB could help -- it gives us an upgrade to 5.1, is supposed to be a drop-in replacement for MySQL, and uses a replacement for InnoDB called XtraDB that looks like an improvement. On the other hand, packaging is a bit lacking at present. Drizzle also looks interesting, but it would require more work to remove the MySQLisms from Koha that Drizzle doesn't use.
As far as Postgres support is concerned, I'm all for it. Of course, Chris' DBIx::Class RFC [1] is the current candidate for starting to get there. However, I would point out that a full implementation of DBIx::Class does not guarantee that we'll also get full Postgres support for 3.4; there is a lot of testing that would need to be done.
[1] http://wiki.koha-community.org/wiki/RFC_for_using_DBIx_Class_in_Koha
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com
2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
I also think DBIx::Class is definitely the way to go. Here's a question:
Is there any way to store the database schema in an intermediate format that can be used to create the database in MySQL, Postgres, or what-have-you? Perhaps there is a way to use DBIx::Class or another module to generate an agnostic schema from the current MySQL one? Caveat: This just popped into my head, I have not done any research of any kind.
I believe that Chris C has already done this to the point of creating both MySQL and PG db's from the same DBIx::Class schema. Kind Regards, Chris
Is it possible to create db-agnostic row-level locks using DBIx::Class? To+ On Thu, Nov 4, 2010 at 12:30 PM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
2010/11/4 Kyle Hall <kyle.m.hall@gmail.com>:
I also think DBIx::Class is definitely the way to go. Here's a question:
Is there any way to store the database schema in an intermediate format that can be used to create the database in MySQL, Postgres, or what-have-you? Perhaps there is a way to use DBIx::Class or another module to generate an agnostic schema from the current MySQL one? Caveat: This just popped into my head, I have not done any research of any kind.
I believe that Chris C has already done this to the point of creating both MySQL and PG db's from the same DBIx::Class schema.
Kind Regards, Chris _______________________________________________ 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/
Hi, On Thu, Nov 4, 2010 at 12:34 PM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Is it possible to create db-agnostic row-level locks using DBIx::Class?
True row-level locking is purely a function of the DBMS; DBIx::Class can't create such locks if the backend database doesn't support them. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
On Thu, Nov 4, 2010 at 1:50 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Thu, Nov 4, 2010 at 12:34 PM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
Is it possible to create db-agnostic row-level locks using DBIx::Class?
True row-level locking is purely a function of the DBMS; DBIx::Class can't create such locks if the backend database doesn't support them.
Yes, what I meant to ask was if switching to DBIx::Class could prevent us from using those kind of locks that could help on several areas where concurrency might be seen as an issue. I don't know postgres's syntax for START TRANSACTION or if the semantics of mysql's 'SELECT... FOR UPDATE' can me mapped by that library into that postgres uses. To+
participants (4)
-
Chris Nighswonger -
Galen Charlton -
Kyle Hall -
Tomas Cohen Arazi