Slashdot Mirror
MySQL to Adopt Solid Storage Engine
hmart writes "As seen on ZDNet's Open Source Blog MySQL is taking another step to defend from Oracle's recent acquisitions of InnoBase and Sleepycat. From the article: 'MySQL responds by getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June.'"
It seems that Oracle is not taking the threat from MySQL lightly. The purchases they have made have been quite public, but they also have been quietly hiring developers from many different open source projects. It is scary how many of them have dropped off the radar. On a side note: I was always under the impression that MySQL was a 'amateur' database. I was very surprised when I was forced to switch from Microsoft SQL 2000 - MySQL had a much smaller memory footprint, and the performance just blew me away. To this day I still cannot believe the performance difference. It really speaks to the power of Open Source.
buy out Solid Information Technology.
-Larry Ellison
Did they learn from Microsoft? Why can't they put together their own solutions?
So mysql will now have solid storage? Finally! Oh wait, it's " Solid Information Technology". Never mind...
___
If you think big enough, you'll never have to do it.
web apps are going to have to be re-written because of this?
perpetually dwelling in the -1 pits
Does anyone know where I can find more info on the sorts of options/features this storage enginge supports?
For that matter can anyone point me somewhere which describes the deliniation of responsibilities between generic MySQL code and the storage engines? In particular is MySQL just an SQL query parser/optimizer stuck on top of storage engines?
If you liked this thought maybe you would find my blog nice too:
No matter which storage engine you use in MySQL, the SQL syntax is still the same. All you have to change is the ENGINE= line in your schema definitions.
I think they have one...aren't they just buying the competition?
We used to use a Solid SQL database a few years back, before I really knew anything about databases or SQL. It was extremely reliable, fast enough for everything we did, and very easy to administer (even for people who didn't know anything about databases or SQL). I haven't used it recently, but if their technology is still top-notch, this will be very good news.
My Web Page
Here's a different idea. Don't reinvent the wheel.
I don't want knowledge. I want certainty. - Law, David Bowie
You might adopt different strategies in code to deal with storage layers that supported different levels of transactionality or locking atomicity.
What does this mean to the casual MySQL user? I'd read TFA but there wasn't one.
You mean hire Sybase to write a database engine for them (up to version 6.5 SQL Server was a Sybase product) and then head hunt a bunch of Oracle DB experts to build your own version (which is what they did when they cut over to version 7)?
putting the 'B' in LGBTQ+
As Mysql continues to catch come towards the Mid-tier in the market, Postgresql is charging at Oracle.
The entire Database market is heading towards OSS.
Thought MS bought Sybase at version 6.5. Did they also pay for development before then? I knew that's where MS got SQL server from but didn't know they paid for it's development pre-6.5
And lets all be glad that MSSQL is secretly Sybase under the covers. Because of this we have the beautiful FreeTDS packages for Perl that happily talk to MS SQL server. Those of us stranded in MS shops can actually work this way, imagine the bloodshed if MSSQL was completely proprietary!
I want to delete my account but Slashdot doesn't allow it.
MySQL is a company, they can either go out, do a SUN Microsystems and re-invent the wheel (as the case of their continuously promised, improved sound API that hasn't seen the light of day) and find themselves further behind the eighth ball OR they can go out, find something that is around 70-80% of what they need, and spend a few months writing up the last 20% which the software doesn't address.
Its all about product turn arounds, getting to market, and ensuring that YOU and YOUR company have the best end to end solution money can buy - so compelling that the customer jumps face first into the contract and wants to sign up instantly.
Because Microsoft is going with a Liquid Storage Engine.
Within two clicks of the Slashdot story page, I found THIS.
If you want news from today, you have to come back tomorrow.
If there is a problem with mySql, one could always migrate to Postgresql. Postgresql is well known for its advanced features and its excellent ability to work with large-size dbs.
Does anyone know if soliddb can do fulltext search? That one thing that annoyed me about Innodb
you could give postgresql a look-see. Might be your answer.
Isn't it better to have a choice of technologies? Also isn't it better to have friends and partnerships than make enemies or treat everyone else as foe? Isn't it better to be able to choose how you want your data stored than to have no choice whatsoever? MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV - or if you have very specific requirements, something you put together yourself - the code is all GPL open source.
Besides, the most complex part of any modern database system is the optimizer - which has to use many heuristics to guess an optimal way to retrieve the data requested taking into account what indicies are available and the performance characteristics of the underlying storage engine. The actual storage engine only has to be as fast as possible in execution and keep transaction state and isolation between connections (for transactional storage engines). A good transactional storage engine takes a long time to design and an even longer amount of time to prove. I am sure that DBAs would much prefer to entrust their data to an engine which is based upon proven technology than something which is unknown and all new and shiny.
Freedom of choice is always a good thing.
MySQL is not about having cheap database... MySQL is about Freedom of choice.
(disclaimer: opinions are my own and not of my employer or anyone else)
No sig. Move along - nothing to see here.
Microsoft and Sybase forked from each other long before 6.5 -- it was back in the 1980s.
Whenever I hear the word 'Innovation', I reach for my pistol.
No reporter would miss an opportunity for a solid pun like that ;)
It's the sound of Oracle money flushed down the toilet. :0) Man, that Ellison guy must be MAD right now.
I guess somewhere down the line MySQL users will be pressured to move off of innodb onto this Solid DB. (At which point, we might see some community backlash and a big controversial fork where the community makes a GPL-only version of MySQL to maintain InnoDB support -- which would please Oracle greatly.)
I hope the MySQL has gotten something in paper that will make sure that this is the last time that users have to migrate. Sure, they can claim that a migration will be seamless, but who's going to be foolhardy enough to risk their data on a transition like this without significant testing?
Actually, now that I think about it, I don't know if it is reasonable to expect users to switch "just" so that MySQL will be able to sell commercial licenses to their drivers and what not. The switch to InnoDB took years (and it's probably still ongoing for many users), but in return, those who switched got a lot of new features that made it worthwhile (probably). This time around, there is not much of an incentive for end users -- assuming that the feature sets will be roughly comparable between InnoDB and Solid.
MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV
"Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:
(1) "MySQL has many applications written for it"
* Not if you enable strict mode, or if you use storage engines that don't support the features you need.
(2) "MySQL is optionally SQL compliant with strict mode"
* Only if you want to forego 99% of the existing MySQL applications, and start fresh.
(3) "MySQL has transactions"
* Not in MyISAM, which means no full text indexing.
(4) "MySQL is free"
* Only if your application which links against the client library is also GPL.
(5) "MySQL is fast"
* Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.
I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.
Social scientists are inspired by theories; scientists are humbled by facts.
I don't know anything about InnoBase but I do use BerkleyDB (as part of Bogofilter) and I know that Sleepy Cat dual licenses it under a commerical and an OSI approved open source license. While I understand that Sun could try and close the BerkleyDB source code, wouldn't MySQL be able to fork it and continue on their own?
I looked at the license for BerkleyDB and didn't notice anything that would prevent forking. Am I wrong?
http://www.sleepycat.com/company/oslicense.html
But my long term strategy is to buy Oracle. Open source DB will die, be resurrected and die again.
Is that you?
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Myth used to scare people away from opensource GPL code.
Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.
There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
No sig. Move along - nothing to see here.
First it was ACID. And now they're going SOLID? Make up your minds! :P
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
I'm just worried about this quote from Solid's V.P. of Marketing: It sounds like MySQL will use only a subset of the Solid product. So how good this news is will depend on how complete a subset of its product Solid opens.
If you took a look at the BDB source code, you're understand immediately why forking this is not an option unless you happen to have hired the developers.
My blog
I get you point... Choice sucks.
This means that every component MySQL uses must be a) GPL licensed, and b) produced by a company willing to sell commercial licenses through MySQL.
I have been using Perl for 5 years. After 1 month with Ruby, I'm not going back.
That's like saying "i have been eating dogshit for 5 years. After 1 month with steak & eggs, i'm not going back.". Hardly an impressive statement at all.
PostgreSQL is superior to MySQL in amny ways ... I have been using Perl for 5 years. After 1 month with Ruby, I'm not going back.
Ruby has many advantages over Perl and Python
while it may be superior (I still don't know if I believe this), the support is still not there. The mysql/php combo is installed on most web-hosting providers.
There will be no need to pressure existing users off from InnoDB .... InnoDB is GPL code and as such will always be available: This is the strength of open source software, it is very hard for players to pick up their toys and leave the sandbox. If they leave the sandbox, they have to leave their toys there. Besides, Oracle has stated that they do not intend to change Innobase's business. Lets hope that they keep that promise.
Of course, MySQL can encourage people to use a particular product choice based upon future roadmaps but I don't imagine that InnoDB support will ever be axed.
(opinions are my own, not of my employer nor anyone else)
No sig. Move along - nothing to see here.
the whining from the postgresql camp begins .................... now.
Insiders claim that the liquid storage plans went down the drain when an executive bumped into the file server and spilled hundreds of critical files.
(3) "MySQL has transactions"
* Not in MyISAM, which means no full text indexing.
I kind of fail to see what problem you have with that...
Why not have MyISAM-table for text queries and link back to the main tables? Would give you an opportunity to choose which fields to add text data from before indexing too. You can use InnoDB for everything else.
The full text indexes get pretty huge, pretty fast. Using them on a huge product table wouldn't be very wise at all.
This is typical LAMP programmer thinking. What do I need transactions and data integrity in a database for? I'll just code the checks into my application. I prefer instead to put checks both in the database and in the application.
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.
I'll stick with PostgreSQL. Unlike MySQL, PostgreSQL is a serious alternative to Oracle or MS SQL. It is also BSD licensed and thus there are zero restrictions on its usage within a commercial product and there is no need to purchase a commercial license.
MySQL is okay for the LAMP mentality but when you start getting in to ORM/ERM (Object/Entity relational mapping) with packages like Rails's Active Record or WebObjects's Enterprise Objects you need a more serious database. As another poster has pointed out in this thread I give it only a few more years before mainstream open source web development moves into the ORM camp.
What's with the different engines in MySQL? I understand that they're different, what I'm trying to understand is why MySQL gets some other company's engine and uses it? I mean, I thought MySQL WAS a database. How can you still call MySQL using InnoDB, MySQL?
Really, I'm confused. Is there really all that much more to a database than a database engine?
Hmmm, any real reason why they don't just take postgresql and use that as their backend?
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL.
True. However, the modified version need only be GPL'd if the modified version is distributed. From the FSF's GNU GPL FAQ:
The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Mmmm'kay... so if there is a performance bottleneak in accessing a table which is essentially constants, the developer decides to simply hard code all that rather than keeping it all in the database. Great. Seen it done many times.
I personally know of many companies which make use of MySQL and have never publically released any code and are still abiding by the GPL. MySQL obviously encourages support contracts for companies using MySQL internally but does not force people to license MySQL in the non-GPL form if their use of MySQL is strictly internal. ie: no binary distribution etc.
I personally use BSD-style licenses for many of my personal project code (see for example the PC-Net simulation code in Xen) but I will equally defend the GPL against FUD attacks. There is nothing stopping companies from using GPL code within their organisation.
(opinions are my own and not of my employer)
No sig. Move along - nothing to see here.
Postgres used to be superior to MySQL in many ways two versions ago. It was much stronger and faster and it used to allow you some actions that were imossible with MySQL like DELETE in multiple base at once. But Postgres also had some problems like the impossibility to alter a DB once it had been created, forcing you to re-create a DB if a minor modification was needed. Now MySQL has evolved a lot and is basicaly at the same level but indeed with a lot more support.
this is not about modifications, but about linking. Only a GPL program can link against a GPL library without violationg its license - see also the GPL FAQ here and here.
The only problem with those of us sticking with PostgreSQL (I'm one of them) is that we're not as widely supported... and MySQL with it's huge market share is.
For example, I just finished an application, and writing the server installer in windows just sucked... whereas the big installation players all have simple plugins to setup a MySQL server and load the information with no difficulty whatsoever, made me jealous. Still not switching, I love me my postgresql.
There is a world of difference between "MySQL to Adopt Solid Storage Engine" and getting "Solid Support", as in, from TFA: "...getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June".
Solid is just offering YA storage engine that works with MySQL, and they happen to be GPLing it. This does -not- mean MySQL is adopting anything from Solid.
Slashdot editors: please read TFA once in a while and please stop writing misleading headlines.
Says here that the marketing VP quoted in TFA, Paola Lubet, used to work for Oracle.
Now I wouldn't want to read anything into that, I'm guessing there's a lot of rotation between database companies, and it's a private company held by a bevvy of investors, so Larry Ellision presumably won't be able to drop it in his shopping basket when he pops out for some milk. On the other hand the investors sound like venture capitalists (I may be wrong, corporate finance is not my field) who might be interested in any short-term returns on their investment that a large, cash-rich company could offer.
Tainting does seem to be a big issue for us developers.
I'm not thinking about the move from a CS to OSS project but just getting hired by another company who are extremely risk averse. For example if you've seen Sun's Java source code (who hasn't Sun were pimping all around the shop at one time) there is no way IBM would hire you to work on the J9 JVM.
It seems crazy though, what actually adds value to you as a developer stops you working elsewhere.
Right now the motivation is not there because MySQL works so well.
YouStockIt - Education through Unorthodox Methods
Actually, Sybase partnered with MS and Ashton-Tate (who wrote dBase) in the late 1980's to make the OS/2 port of SQL Server. When MS wanted to port it to Windows NT, they wanted to add things like threads (for SMP support, which OS/2 didn't have) and async I/O. Since this would totally break with the Unix model which didn't have these things (remember, this was early 1990's), MS broke off the deal with Sybase.
The first version of SQL Server after forking the code was 6.0 (the previous version was 4.2, which was just a straight port from OS/2), which had the same storage format as Sybase. Keep in mind, though, the code had to be substantially rewritten to support threads, async I/O, completion ports, and all other features that were specific to NT.
MS SQL 7.0 was a total rewrite to break free of the ancient storage format, and the latest version bears almost no resemblance to the Sybase product beyond basic compatibility with Transact-SQL and maybe the network protocol.
dom
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
But all the other databases seem to have mostly SQL standard syntax AND a large number of applications written for them.
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Yes, transactions are not required for every situation. I never said that they were. My point was that to achieve the advertised performance numbers that MySQL advocates give out, you have to sacrifice transactions. To get the advertised full text indexing you have to sacrifice performance.
Myth used to scare people away from opensource GPL code.
If your application links against the client library, it must adhere to the GPL. This is NOT a myth unless you know of an alternate client library.
Social scientists are inspired by theories; scientists are humbled by facts.
How does perl's DBI work? I am under the impression that it uses the MySQL client libraries and I am also under the impression that using DBD::mysql doesn't mean that my application has to be GPL.
Any takers?
I found this page which states that DBD::mysql uses the MySQL client libraries (It says this for Net::MySQL).
.. Any takers?
If you perldoc DBD::mysql, it says it's licensed under the same license as perl (the artistic license).
Unless DBD::mysql is saying that their code is licensed under the artistic license, but as soon as it's built against the MySQL client library it becomes GPL (and just leaving out the last part), I don't see how the MySQL client libraries could possibly be GPL only.
Why not have MyISAM-table for text queries and link back to the main tables? Would give you an opportunity to choose which fields to add text data from before indexing too.
You could say the same thing about any data in a database at all. Transactions are useful on a table with a FTI just like on any other table.
Let's say that you want to make sure that a full text record does not exist without it's accompanying information (perhaps in a one to many relationship).
A text field doesn't seem at first like the typical bank account example that everyone uses to explain transactions. However, transactions are just as important for any data type.
Social scientists are inspired by theories; scientists are humbled by facts.
And the support will never be there unless there is demand for it or people writing web applications in language other than mess that is php.
...and that is all I have to say about that.
http://jessta.id.au
I still fail to see how adhering to the GPL would prevent a company from actually using GPL products. The GPL would only come into play if the company was distributing software products and services which made use of or was derived from GPL code. The last time I checked, the overwhelming majority of companies on this planet are not software companies.
No sig. Move along - nothing to see here.
It also means that the only code on your application that needs to be GPLed is the one that talks to the database. I usualy never talk directly to the database anyways, so this is hardly an issue to me.
Look at the bright side, at least it will force you to decouple your application from the data storage. I know that this may not be possible for some applications, but nowdays I guess most applications that deppend on a database for data storage are Web-based... so deattaching them from the database can do only good =D
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
Antony, you've missed the point twice on the trot regarding the licensing issue raised by the GP.
It's not about whether or not a company gets to use MySQL internally, it's about whether they can link their own products against it, which they cannot - unless they pay MySQL AB for a license, or GPL their own product.
I would opine that the GP's point is a bit naive - why shouldn't an enterprise pay to use GPL code in a non-GPL work? - but you failed to address this and answered a different question.
Just to sharpen up your points.
Data integrity != transactions, each database write in Myisam is just the same as an Oracle write, with the same OS calls. The only gain from transactions is grouping of multiple changes into 1 operation so they all-execute or none-execute. Which gains you nothing if you only make changes to *one* table at a time, or read settings from tables.
The GPL fud is just fud, you can dynamic link to MySQL client just like any other DLL.
In addition to not having to be a GPL'd program to use GPL, you can even early link to it if you are not distributing the software, or are under other FLOSS software license.
So you can even make a closed source product, sell it under whatever license you like, distribute the mysql client in DLL form, and you are free to do whatever under whatever license you like. He was careful to say "link to", without mentioning that its not necessary to link to the MySQL library.
So they're interesting talking points, but nothing of substance.
So MySQL is keeping up to Oracle's increasing power - that's good! What about PostgreSQL though? What are they doing to keep up? Anyone know?
"It's not about whether or not a company gets to use MySQL internally, it's about whether they can link their own products against it, which they cannot - unless they pay MySQL AB for a license, or GPL their own product."
r y/l-dll.html
Here's how to make a DLL in Linux:
http://www-128.ibm.com/developerworks/linux/libra
You compile the MySQL client as a DLL and LATE link to it for free, or as you said, pay the license if you can't be bothered to do that. All of this is unnecessary if your software isn't for distribution, such as server side web projects, or is under other FLOSS licenses, which is also permitted (e.g. the Apache License).
... while others (PostgreSQL) have all one needs. I guess that's an unavoidable dynamic of free software (and a good one as well -- just like in other competing open source projects). So probably one day MySQL will have everything that PostgreSQL has today, but why wait ? It's mostly transparent to move from one to the other, and there are tons of guides and scripts to convert from MySQL to PgSQL. Even PhpMyAdmin has its Pg pendent (PhpPgAdmin).
And it's painful to go back when you've learned to do proper logic separation using stored procedures, triggers, views and transactions, things that way too many projects duplicate in the PHP or Ruby front-end, relegating the DB to the "simple" role of being a storage backend (even Ruby on Rails forces you to think that way via the MVC architecture).
For that purpose, use SQLite -- it does what you need, is very high performance (on-disk, non-concurrent access -- can't get any faster than that). For real solid DB work, with garanteed integrity, just the way RDBMS were meant to be, go for PgSQL.
we're using HP data protector backup/restore software, which uses solid as its database for storing all data information.
HPDP itself is as stable as an italian taxi driver stuck behind two priests in a skoda, but thank GOD, the database is rock solid and doesn't corrupt when HPDP goes belly up again.
so all in all, a good pick of mysql!
On a long enough timeline, the survival rate for everyone drops to zero.
There are quite a few properties that can be altered without having to backup, drop and recreate the database. The only sometimes-handy-to-have thing that I can't really see being present is changing the character encoding of an existing database.
while true; do eject; eject -t; done
The 'P' in LAMP denotes use of a dynamic scripting language (Perl, Python, PHP). If it bothers you, perhaps you should just change the name of Ruby to something beginning with 'P'. Personally I prefer lua to ruby. Ideally, I'm would like to target Parrot or nekovm but would not unduly discount Pike or ferrite either.
Well, according to Google:
"Eating Dogshit": 1,220
"Eating Steak & Eggs": 43
I'd say more people are eating dogshit than eating steak & eggs. Godbless the interweb!
I'm going to go create my own technology news site, with blackjack and hookers. You know what? Forget the news site.
(4) "MySQL is free" * Only if your application which links against the client library is also GPL. Myth used to scare people away from opensource GPL code.
Has nobody here even bothered to look in the EXCEPTIONS file in the source? You are allowed to directly link to the client code if your choice of license is one of those listed in that file too. It is not *just* GPL.
So, what happens if after spending a bunch of time working the kinks out of a Solid io plug-in Oracle buys them? Oracle is quickly robbing mysql of storage options, and is positioned to do this indefinitely.
Looks to me that mysql only has two options:
1. do what *every* other database vendor does - and build their own backend
2. use postgresql as a storage plug-in
Of the above option #1 is obviously the most attractive in the long-term, but option #2 has quite a few benefits:
* faster to implement than option #1
* postgresql can't be bought by Oracle
* immediately benefit from the most mature open source database technology
* stop any drain of mysql users to postgresql
I have no idea how the licensing would work, but would love to see postgresql & mysql have a positive relationship in which they could each benefit from each other's technology, market, etc.
(4) "MySQL is free" * Only if your application which links against the client library is also GPL. Myth used to scare people away from opensource GPL code.
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.
No, you 'must abide by the terms of the GPL' only applies if you redistribute your linked code outside of your company. I would wager that there are quite a few cases (probably the majority) in which this is not necessary at all. This "GPL is viral" crap is so 2005--why don't you come up with some new anti-FOSS FUD to sling at us?
"City hall" in German is "Rathaus" Kinda explains a few things......
No, you are stupid. All of these apply to works that you distribute -- the same as if you were distributing a modified work. This does not apply to internally used programs -- it would make no sense for the GPL to apply in such cases!
The GPL states that you must make the source code for your program available to anyone you give the program to. If you truly feel you must apply the GPL internally, then you must make the code available to yourself and the employees of your organization...is that really a problem for you? Are you worried that if you allow the people developing your applications to have access to the source code for those applications, it will hurt your interests?
BerkeleyDB, InnoDB, and now this new one, provide the actual backing store; e.g. what gets written to the disk. MySQL is, as far as I've been able to tell, basically a front end that gives a SQL interface to dealing with records stored in files maintained by one of these other products.
That said, this is no trivial feat; the raw BerkeleyDB is not very user friendly and I wouldn't even know how to optimize access to it (I've used it for a couple of small projects that needed a little more than flat files, but not a full blown db). What MySQL has done is provide the standard SQL language and some extra code to optimize to the best of their ability the retrieval and storage of records from these binary files.
It's also these back ends where MySQL gets things like ACID; it's up to the back end to make sure that the data can be written completely in one shot, and if not, somehow signal the MySQL part to activate a rollback (I'm presuming here...I'm not certain this is how it works in MySQL but it would make sense insofar as they're backend agnostic).
As one who has foolishly written a database back-end system, I can attest that it is *not* trivial and while Oracle's purchases may just be predatory, they did get some good technology in the process (though I'm guessing neither holds a candle to Oracle's) and I can see why they'd want to throw their hats into another company's ring instead of taking on the task themselves.
> Isn't it better to have a choice of technologies?
uh, better than what? If the answer is stability, then no.
So, MySQL has the following storage plug-ins: MyISAM, Innodb, Sleepycat, etc, etc, etc. as an enterprise data architect (ok, sounds pompous, how about someone that implements a *lot* of database solutions) I really don't care about a wide variety of storage engines that mostly don't meet my needs. Of all of the above, only Innodb is a good general-purpose solution. The others are useful only in specialized circumstances or are obsolete.
The idea that multiple storage engines is a great idea is just market spin.
Oracle, DB2, Informix, Sybase, SQL Server, Teradata, Postgresql, Firebird, etc - all have their own. There is no risk to the user that another company is going to buy out their storage engine, force the database vendor to perform an expensive switch and possibly impact functionality or licensing for my applications.
If MySQL wants to support multiple storage engines that's fine. Not terribly attractive to me, but fine. But first - it needs to own its own. And its own needs to support ACID as well as non-logged activity. This shouldn't be news to anyone: this is what every single commercial database provides and has been the way to do it for 20+ years. It's still the way to do it.
> Freedom of choice is always a good thing.
> MySQL is not about having cheap database... MySQL is about Freedom of choice.
How about cheap, full-featured, standards compliant & stable RDBMS? Why isn't this a possibility? This is what I want, not freedom to pick from a pack of obsolete, special-purpose or dead-end storage options.
At last! A reasonable sounding criticism - so rare on Slashdot.
What would be the list of priorities for you for features/changes to be made to MySQL in order for you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers so delivering on all of them overnight would not happen.
What would be the minimum set of requirements for you and what would comprise the expanded set which would be nice to have but not immediately urgent.
No sig. Move along - nothing to see here.
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.
That is *if* you link to them and only *if* you decide to resease your software. Most modern projects use some kind of database abstraction layer which would free you from any licensing obligations (as well as unnecessary DB lockin) And most people using MySQL are using it for internal projects and web sites. For 99% (made up number) of uses, MySQL is free from cost or obligation.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I haven't heard/seen anything from the MySQL camp officially, but I'd bet that they are ADDING Solid, not necessarily replacing InnoDB. Of course, for the commercial license they will have to do this, but not for the GPL version.
I'd like to see some official comment from both companies, rather than take a blog entry as gospel.
Hmm... some not-so-definitive information:p ?p=30167&rl=1
http://www.samspublishing.com/articles/article.as
The last time I checked, the overwhelming majority of companies on this planet are not software companies.
But many companies do copy code to one extent or another. If a company has some code under one license (perhaps that they purchased), it is likely incompatible wit the GPL and MySQL could enforce against them.
Making client libraries GPL is uncommon and certainly a caveat of using MySQL. It is not a myth. If you understand the implications and you're OK with it, that's fine.
My whole point is that most RDBMSs don't force you to make all of these sacrifices. If you want FTI you lose transactions (and a lot of other features), what kind of a sacrifice is that? Everyone says that MySQL is easy but to understand all of these tradeoffs is not easy at all.
Social scientists are inspired by theories; scientists are humbled by facts.
Why the hell was this marked as troll?
I was merely stating that mysql has more support in the IT field (which is true).
If they don't distribute, how are they infringing the GPL? Or perhaps you are talking of other licenses which forbid exposure or linking to GPL licensed material?
Honestly, I want to know.
No sig. Move along - nothing to see here.
Chicken Littles will be disappointed - See Zack Urlocker's blog:
After InnoDB, Solid isn't MySQL's only high end option either. Jim Starkey seems to be working on an OLTP engine after being strategically hired; and who knows what interesting things might come out of MySQL's association with MaxDB (former SAPDB).
you had me at #!
> What would be the list of priorities for you for features/changes to be made to MySQL in order for
> you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers
> so delivering on all of them overnight would not happen.
Now that MySQL has implemented most of the standard database features, the next step is to harden them and the rest of the codebase. At this point I'm not interested so much in features as I am high-quality & robust implementations.
- this means that if I add a column to a table I won't have to spend hours copying the data back & forth under the covers
- it means no more gotchas - with broken date handling, exception handling, type conversions, value truncations, etc.
- it means that individuals clients shouldn't be able to turn off strict mode.
- it means that non-strict mode should be deprecated - and gone in a few years
- it means that the optimizer should be able to handle very complex joins and almost always come back with the very best possible query
Now, *after* the above have been addressed there are some additional features to add. These are mostly oriented towards reporting functionality, where I think mysql is pretty weak right now. My list would include:
- oracle-style range partitioning: this means that you can using mysql for large reporting & warehousing applications. We're not talking union-all-views here, but the ability to attach & detach partitions, and disregard partitions of data from queries. I often see 10x performance gains from partitioning over indexing in this kind of app.
- query parallelism: need to be able to split reporting query work across CPUs. These large queries, often scanning a 100,000+ rows can typically get linear performance improvements in my experience from query parallelism.
- automatic query rewrite: need to be able to automatically rewrite queries in order to hit summary tables if they exist. This is critical for some types of powerful reporting tools, or reporting performance boosts for commercial apps.
- materialized views: simple method to manage summary tables. Not critical since this can be developed in other ways, but this has become the preferred way to manage summary tables.
- federation: the ability to redirect a query against a table to another database to be resolved. This allows you to define reference tables on one database, then share them across many.
- query failover: the ability for the mysql client to automatically reroute a query to a failover server. This allows you to provide failover without any code changes at the application layer.
that's all i've got time to write, but should cover most of what I'd look for first.
Support for this is being implemented but it does rely on the storage engine to know what to do. Otherwise, the fallback is to do it the old slow way.
Good suggestions. I'll try to make sure that they're not forgotten.
This would mean breaking backward compatibility - something that I think will be undesirable. There are some embedded applications which do not benefit from strict mode for example.
This is the "holy grail" of database systems... What may seem trivial to us to decide what query plan is best may be non-trivial to calculate. There may be a large number of optimal paths but the optimum one may be very hard to deduce due to local minimas. Many databases have such large and complex query optimizers that the query plans have to be precalculated and cached. MySQL has a skilled query optimizer team and I am sure they will do great stuff.
Already actively in development and may be previewed in the 5.1 tree.
Only available in MySQL Cluster to a limited degree. Tricky to make a general solution but it is something we are aware of.
Already available and in 5.0 tree, although improvements are possible.
AFAIK, JDBC connector already provides this and I think the
No sig. Move along - nothing to see here.
Tainting is make-beleive.
If you want to use a novel algorithm you heard about at your previous job, look it up on the internet. If it isn't there, don't use it. If it IS published on the internet, it is by definition not a trade secret, and you can use it.
If you want to put it up on the internet, find a smart colleague and give him the specs of the algorithm. Let the colleague reverse engineer the algorithm from the specs, and publish it.
If they copy it, they need a license.
Where in the GPL does it permit such copying?
And I'm not saying that it applies to every company. But it does apply to many situations that people may not realize. Most companies at least copy the application a few places around their company, for instance installing on a development machine and then the live server. Perhaps you can try to squeeze that into a legal situation. But it would be very easy to violate that if you aren't careful, which was my point.
Even commercial RDBMSs allow you the ability to link against the client libraries and distribute it. From a logical perspective, most people don't think of linking against client libraries as needing more licenses. But in the case of the GPL, it does. The GPL isn't normally used for client libraries (although it is used for code libraries).
Social scientists are inspired by theories; scientists are humbled by facts.
So you are saying that if I execute "tar -cf
Please read the full text of the GPL, specifically version 2 of the GPL (which MySQL open-source release is licensed under), before you utter such garbage again.
(definitly my own opinions, seriously.)
No sig. Move along - nothing to see here.
It gains you nothing if you make changes to one *row* of one table at a time. This is a fairly rare use case.
I'll stick with PostgreSQL. Unlike MySQL, PostgreSQL is a serious alternative to Oracle or MS SQL. It is also BSD licensed and thus there are zero restrictions on its usage within a commercial product and there is no need to purchase a commercial license.
Let's look at all of the major postgres serious alternatives. EnterpriseDB et. al. aren't offered as an open source application because the license allows them to insert their own proprietary extensions. This leads to fragmentation.
GPL a bad thing? I think not. If it is, sometimes it's the less of two evils.
I am no GPL FUD-monger. I've got some patches in the Linux kernel (GPL). Some patches to WINE that have since been mostly replaced (now LGPL, was WINE license, I agreed to the LGPL change). Finally, I have a pretty significant amount of code in wxWidgets (wxWindows license which is LGPL with an exception to allow static linking).
My main reason for choosing PostgreSQL over MySQL was my use of WebObjects which is essentially an ORM based around the concept of transactions (except in the object model it's known as an "editing context"). A secondary concern was that if my internal project were to go commercial (and it's possible) I would like the freedom to license it as I see fit. Keep in mind that I actually DO believe in a lot of what Stallman says, including the part about it being unethical to distribute a binary without source. However, I sometimes disagree with the particular implementation of that belief which is embodied in the GPL. So a secondary concern for choosing PostgreSQL over MySQL was definitely the licensing of the client libraries.
I should also point out that if you read the GPL more closely you'd realize that dynamic linking does not in fact remove the requirement to license your linked code under the GPL. That is what the LGPL is for. However, I note from another post in this thread that MySQL apparently has an EXCEPTIONS file detailing what other licenses are allowed.
On the topic of the LGPL (and now I'm getting off the subject) it's worth noting that it is a common misconception that the LGPL requires dynamic linking. What the LGPL actually requires is a means for the end user to relink against a newer version of the LGPLed library. This is generally accomplished via dynamic linking but can also be accomplished by distributing an archive (.a) file or a collection of object (.o) files that can be relinked with an updated version of the library using the static link editor.
The GPL on the other hand does not state anything like this as the GPL strictly requires the entire work to be buildable from source.
Perhaps I have a skewed view because in my case I'd select the "Share all objects" for the particular entity (table) in EOModeler and all of the constants would be pulled into the shared editing context at startup time.
So what? I can choose to use EntrerpriseDB or I can tell them to shove their closed source product straight up their ass.
Which two evils? The GPL is definitely not evil. Nor is code forking.
In my case I am using WebObjects. It is essentially an ORM (similar to Rails's Active Record) but built around the concept of database transactions instead of Active Record's concept of saving the root of an object hierarchy.
Enterprise Objects (the data access/control portion of WebObjects) functions by having the programmer do inserts, updates, and deletes in what is known as an "editing context" (sort of an OO equivalent of a transaction). Editing contexts can be nested (similar to how you can begin and commit or abort a transaction within another) and when a root editing context is asked to save its changes (equivalent of SQL COMMIT) it opens a transaction, issues all of the insert/update/delete commands, and commits it.
Now, of course I could ignore the transactional functionality and craft my app such that each change results in a call to saveChanges on a root editing context. Except I don't want to do this because I've written my app using Direect2Web and the UI for direct to web just doesn't mesh with the old-school concept of having one web page to edit one table.
What I have instead is an interface where the user is effortlessly traversing the database. The UI is not task based but rather based on the underlying data store. Now you'd think that Joe User wouldn't be able to figure this out but the surprising thing I've found is that I start hearing of users doing things I never even intended to happen. I do start each user out at a home page with a list of common tasks but from there the user traverses the object graph in a natural way.
I couldn't even imagine using MySQL for this. Without transactions I'd have to be a lot more careful with my validation routines. With transactions I can depend on the fact that when (not if) I make a mistake the DB will catch me. And I know the DB will catch me because in order to easily access related data I need to model the relationships in EOModeler. When creating DB tables from EOModeler I automatically get the proper deferred foreign key constraints that fire upon transaction commit which happens at the end of the editing context's saveChanges method.
Aside from transactions though, I really don't use any of the more advanced features of PostgreSQL. Ironically, Apple supplies a (closed source) MySQL plugin for EO but not a PostgreSQL plugin. I must admit I was a little leery of that because in this case I could not expect to reasonably abide by the terms of the GPL (even if I'm distributing within my own company) because I simply do not have the source to Apple's adaptor (even to distribute within my own company). That was a risk I could not take. Couple that with the fact that WO really works best with a transactional DB and MySQL is simply out of the question.
It should also be noted that the open source alternatives to WebObjects based on the old Objective-C interface (WO 4.5) both use PostgreSQL almost exclusively.
How can you avoid linking to the MySQL client library and still use MySQL? The only way to do this would be to reimplement it. Even the JDBC client library is GPL. I am not sure how you (and some other people around here) figure that dynamically loading after app startup somehow differs from having the dynamic linker load a library just before your main function is called. It seems q
It gains you nothing if you make changes to one *row* of one table at a time. This is a fairly rare use case.
;)
;)
Says who? I develop a database-heavy webapp and a quick grep through the query logs show that about 96% of UPDATE queries include a WHERE clause that specifies a primary key value, and thus by definition only change one row.
Applications are all different. I'm sure there are loads of applications where single-row updates are extremely rare, but your application is not my application
The app I develop has never needed to use transactions, and I've never felt that the client code would be any simpler if transactions were available: it just is that way, for what I'm doing. So MyISAM is a pretty good choice - it means the app runs nicely fast, even though it does a lot of queries.
It works fine on PostgreSQL too, the DB layer can be switched straight over. I've not benchmarked one against the other, but I would be surprised if the MyISAM performance was worse
Choices are a great thing: for every task where MyISAM would be hopelessly inadequate, there's a task where it works just fine.
I develop a database-heavy webapp and a quick grep through the query logs show that about 96% of UPDATE queries include a WHERE clause that specifies a primary key value, and thus by definition only change one row.
Yes, but how many of those 1-record-updates were triggered by a single "transaction". If I write a loop which updates records one-at-a-time then you'll get a million 1-record-updates, but that doesn't mean that it wouldn't benefit from being enclosed in a transaction.
Also - atomicity is about more that DB writes. What happens if you query the same record 5 times in generating a report/webpage/whatever. If you enclose the SELECTs in a transaction they are guaranteed to return the same result. If you don't then they could be inconsistent. All a transaction does is make DB IO seem instantaneous, even if it wasn't. With a transaction, you can do a SELECT that returns 25 GB of data over a DSL line, and the last record returned was in the state it was the command was issued.
Now, I still think that allowing transactions to be disabled for the sake of performance is fine, as it gives control to the developer. However, I'd only trust a developer to make that determination if they were well versed in DB concepts - far too many folks have a transactions-are-overrated philosophy without understanding why they are often important.
Yes, but how many of those 1-record-updates were triggered by a single "transaction". If I write a loop which updates records one-at-a-time then you'll get a million 1-record-updates, but that doesn't mean that it wouldn't benefit from being enclosed in a transaction.
The database is primarily used to serialise and deserialise state, most pagehits generate exactly one UPDATE to one row (the user's account). There are no loops like that. The data happen to be structured such that the atomicity of writing to a single row is sufficient to maintain consistency at all times.
Also - atomicity is about more that DB writes. What happens if you query the same record 5 times in generating a report/webpage/whatever. If you enclose the SELECTs in a transaction they are guaranteed to return the same result. If you don't then they could be inconsistent.
Which is why the application doesn't do that. The state of each thing the app is interested in examining is fetched from the database a maximum of once in a single pagehit, and in almost every case there is no requirement that the states being read be atomic with each other, because they are independant and no cross-table consistency is required.
All a transaction does is make DB IO seem instantaneous, even if it wasn't. With a transaction, you can do a SELECT that returns 25 GB of data over a DSL line, and the last record returned was in the state it was the command was issued.
I know exactly what transactions do, I've written many apps that use them. But, this one doesn't. It has a local database and it rarely needs to select more than one row or update more than one row at a time.
Now, I still think that allowing transactions to be disabled for the sake of performance is fine, as it gives control to the developer. However, I'd only trust a developer to make that determination if they were well versed in DB concepts - far too many folks have a transactions-are-overrated philosophy without understanding why they are often important.
Where did I imply that transactions are overrated? Transactions are a vital part of many database applications and to try and do those applications without them is foolish. The simple fact I was trying to note is that there are still, whether you have ever developed one or not, applications that have absolutely no use for transactions whatsoever, and thus it's no big deal for them to run on a database that doesn't have them.
I made that determination for my application because I am well versed in DB concepts. A major design principle was to never implement anything in the application code that would have been cleaner/safer/faster to do in the database layer, just to overcome a shortcoming of the database. It was not a design principle to ensure it would work on MyISAM tables, or even on MySQL at all - it just happened to turn out that way because I never needed to overstep the bounds of what MyISAM can do, and that's quite handy because it means the app works for people who use MySQL.
There's a better history in the MS Book "Inside SQL Server". The Microsoft version was originally a port to 16-bit OS/2, and the co-development fell apart almost immediately. So it's really inaccurate to claim that MS/Sybase were ever exactly the same. Close, sure.
Whenever I hear the word 'Innovation', I reach for my pistol.
So you are saying that if I execute "tar -cf /dev/sa0 /boot/kernel-2.6.14-gentoo-r5" and make a copy of the Linux kernel, which is GPL, onto another device, I have to track down all the contributors to the Linux kernel and get permission to do that?
(1) If you are copying files that you already have legally, and you are just incidently copying for basic functionality, it is likely fair use in which case you don't need a license.
(2) The example you gave seemed to be pure GPL. Since you didn't make any derivative work with an incompatible license, I don't see a problem.
(3) Legally speaking, if you copy something (aside from fair use), you need a license. Usually it is prominently displayed. If you are unsure about the license terms you have for a given piece of code, you need to track down the copyright holder and get a license.
Normally this whole process is simple because you just read one file that says "GPL" and it tells you the license for an entire application. Most of the time users merely use the application or perhaps copy it to other computers, and do not create derivative works. For this type of behavior they don't have anything to worry about under the GPL. The GPL is no-hassle when it comes to using and sharing programs.
However, the story is different for developers. Developers, like with any software, need to put themselves in a different frame of mind, about whose code they are using and what licenses that code is under. Developers invariably use code libraries, and for each one they know they need to acquire the correct rights. Let's say they plan to install it on 5 servers and 10 development machines, they need to acquire all 15 licenses for every code library they use developing the application.
The problem is that most people who are writing code that uses a separate database server view themselves as users of that database. If you write code that requires MySQL, you are a MySQL user. However, since the client libraries are GPL, those people are now (legally speaking) MySQL developers, since they are creating a derivative work of the MySQL product. And most people won't realize this until they are told by a MySQL sales rep that they need to pay up.
Of course this is not unique to the GPL. There are a lot of possible licenses for the client libraries that would cause this problem. However, by convention, client libraries are generally licensed under terms that do not create this problem. For example, BSD, LGPL, and many licenses used on the client libraries for commercial database products. MySQL breaks this convention.
Social scientists are inspired by theories; scientists are humbled by facts.
You are using an inconsistant (and possibly very flawed) definition as to what consitiutes a derivative work - perhaps you work for The SCO Group? (joke)
... it does prevent contractors and software vendors from using GPL software as part of the works they supply to another company without including all the source code, correctly licensed.
The GPL requires that the source code is made available to all entities to which the binary is distributed to. This doesn't mean that the company has to put their source codes on a public FTP site but it may mean that every entity which has ownership of any machine which the code runs on has to have access to the source code if so requested. If the company itself owns the machine, then it means that the company must have access to the source code. If the derivative works is supplied by an external contractor, it means that the external contractor must abide by the terms of the GPL and give the company the source code and the code must be correctly licensed as distribution from one entity to another has occurred.
These conditions do not prevent a company from making use of any GPL software
If you are a contractor providing software products to other companies and don't wish to give away your secret source to your customers, I can see why you may dislike the GPL. The spirit and intent of the GPL: anyone receiving GPL derivied works from another entity is entitled to the source. It is a pro-community license.
(opinions are my own, I will not discuss further on this thread)
No sig. Move along - nothing to see here.
I wish i still had mod points.. funny and subtle at the same time...
Sorry - wasn't my intention to pick on you in particular - it just seemed like there were quite a few posts in this general thread along the lines of "who needs transactions anyway."
Obviously if they aren't needed they just add overhead...
These conditions do not prevent a company from making use of any GPL software
I realize that. I like the GPL and I think it's a good license for a lot of software, even some code libraries.
I just think that it is counterintuitive that the licensing for MySQL is similar as if it was embedded in the application you're distributing. Most companies charge for the server and do not charge you to write applications for the server (or some products are always free of charge). MySQL is just the opposite: they give the server away for free and charge for writing applications.
I personally think that is confusing and counterintuitive. I also do not think that MySQL does a good job of clarifying that caveat. That is purely subjective, so I respect your disagreement. However, I think you may have missed my point which is what I'm trying to explain. I do not think it's a "myth" to be concerned about licensing which is counterintuitive to me.
Social scientists are inspired by theories; scientists are humbled by facts.
That was a good book. I recall their being things in that book that I've been unable to find anywhere else.
It seems like MS would have done their significant "rewrite" of SQL server much sooner than 7.0 . 6.5 still used 512b page sizes, devices (agony) and a other triangular wheels. It did leave Sybase behind at that point.
SQL server is one of my favorite Microsoft products. The other two were gorillas.bas, and nibbles.bas.
Preventing devs from doing what they want is a necessary evil, because devs preventing users from doing what they want (by withholding source) is even worse.
Faulty reasoning. I'd say more people google "eating dogshit" hoping to find some pictures of someone eating dogshit than do the same to find a picture of someone eating steak and eggs.