A fork is possible. But what really needs to happen is the MySQL community needs to get it's act together and be independent of MySQL AB. There's a lot of community-building that needs to happen, because right now the whole development process is too dependent on MySQL AB.
This is not a fast process that a few good programmers can solve overnight. You need a few good programmers, a few good organizers, a few good decision makers, users involved on mailing lists, and a lot of time to figure out who does what and when they do it.
The project also needs direction. Will it be the same direction as when MySQL AB was calling the shots? If it changes direction, will the database cater to the same users?
Here's a potential problem I already see: You get all of the above requirements. Some of the decision makers think it's better to move in the direction of standards-compliance, strict error checking, consistency, and data integrity. The problem here is that they will always be chasing PostgreSQL, and their users will go elsewhere.
MySQL is kind of in a precarious position. If it gets "too good", it will compete with the likes of PostgreSQL and Oracle. They need to stay where they are, yet incrementally improve. It seems like any direction MySQL moves, the logical conclusion works against them.
But here's a great solution: mysql could use postgresql for its transaction layer.
An interesting point. One might wonder what it is that MySQL brings to the table if that happened though. Presumably, MySQL would bring nothing other than backwards compatibility with old applications. People would be jumping from MyGreSQL (or whatever this would be called) to the real PostgreSQL as fast as they could.
On the other hand...doesn't SQLite now support transactions & MVCC? And along these lines, could mysql pick up greater scalability by using db2 & oracle as storage layers as well?
MySQL has a commercial version to support. They can't charge someone a license fee and tell them to go elsewhere for a good storage engine. Anything in their GPL version needs to be in their commercial version. Therefore the only kind of code they can include is BSD-like, like PostgreSQL.
I guess they could have some kind of loosely-coupled interface that used another RDBMS as a backend, but again, what does MySQL provide? It would just be a SQL translator. It would be unable to optimize, plan, or execute queries, so that leaves what? Parsing? And then it's re-parsed by the other DB engine? That certainly won't impress anyone.
When a product gets to the point where it's ONLY possible value is backwards compatibility, people port the applications away quickly. [ insert MS Windows joke here * ]
* MS Windows doesn't really compare, since it's easy to replace a set of MySQL servers with a set of PostgreSQL servers, but not easy to replace a few hundred million installations of MS Windows.
The problem that people were having was how close the companies were getting. MySQL seemed proud to work closely with SCO, which was strange. Not necessarily bad, but some MySQL DB users are understandably concerned about the stability of MySQL AB.
The problem that MySQL DB is having right now is that it's too dependent on one company: MySQL AB. And that company is proving that it is not stable enough to count on.
If I were a MySQL DB user, I would be planning for an outcome that did not require MySQL AB, because the company might not be in the same form a year from now. Possibly even choose something else that has a stronger community behind it, or at least a stronger company behind it.
MySQL has a big community, but it's organized not around itself, but around MySQL AB. That may have to change.
You could be correct. I'm guessing that we'll all find out soon enough.
I think that MySQL will face huge problems because of this. It's damning that MySQL AB hasn't even spoken up about it.
It may be that there is some way for MySQL to get it's customers out of this mess. However, if I were a MySQL user, I would certainly be planning for the worst. After all, things look bad. It's almost certain that Oracle did this to quash MySQL, and they wouldn't spend the money if they didn't think it would succeed.
MySQL left itself vulnerable as a company. The MySQL user community left itself vulnerable by relying entirely on one company, with no real developers outside MySQL AB. It looks like it bit them.
The best alternative, should Oracle decide to refuse licensing or extort money from InnoDB licenses in the future, is to fork InnoDB and encourage community development.
That is the worst thing that MySQL AB can do. They would not be making any money from it because they couldn't sell it commercially. The commercial product would then be worse than the community version. And MySQL would have to live with the PR equivalent of a black eye.
That makes no more sense than Oracle supporting PostgreSQL development.
However, that may be good for the MySQL community. The community would have to restructure itself so that it wasn't based around a single commercial company. It would be tough to really progress for a while, but at least the existing users could be supported.
as there is a chance that the contract they signed causes them to lose all rights to sell InnoDB commercially when the contract expires.
I would assume that it's more than a chance. The contract is what gave them the right to sell InnoDB commercially in the first place. And it will expire next year. Therefore, unless it's renewed, they have no right to continue selling it.
However, if they were smart they would have had language in their contract that allows them perpetual commercial licenses to past versions
I doubt that InnoBase would allow MySQL AB to sell InnoDB commercially in perpetuity without additional royalties. That's absurd. That would effectively be like MySQL owning the copyright for themselves.
It makes no difference what the actual mechanism is.
That's because you don't actually have a mechanism. You have yet to give an example. You have yet to even really define what problem you're trying to solve.
I suspect that if there is anything of value along the lines of what you're talking about, it is already easily covered by triggers and listen/notify.
This is a very wrong-headed assertion. If you've got a requirement to individually process each of fifty million rows, which is better - pulling them all across the network to the client app, processing, then pushing them back to the DB, or doing the processing on the (big, powerful, local) DB?
Stored procedures are very important for many reasons, but you are making a wrong-headed decision as well. It's not about keeping logic in the database or keeping logic out of the database. What you need to do is put logic in the database if it maintains your data integrity or if it maintains the API you are providing to a client application.
A general rule is: if it's an inherent truth that has very little chance of changing over time, and it's consistent across all your applications, put it in the database and let the database enforce it. However, if it's just a current business rule that is subject to change, put it in the application.
They can't use their current commercial license with InnoDB unless the copyright holder of InnoDB code gives them permission. They can only distribute it as GPL, which would mean that any commercially-licensed code would be less featureful than the GPL version.
I doubt that MySQL will continue to pay for development on a product that they can't sell effectively.
This is not a well-thought-out feature at all. How is the database supposed to know what data an application *might* access? The database provides all the necessary isolation and notification systems. That's all it can do.
Also, how is the database supposed to notify the application? Would it throw an exception/error/warning/notice the next time you executed some SQL? Would it be a separate API call (in which case, why not just use LISTEN/NOTIFY)? Would it signal your process (thereby killing it if you don't have a handler)?
And the idea of "resolving" these dependencies would require a huge amount of knowledge that the database has no way of knowing.
I think you misunderstand the role of the database, and the relational model. The relational model is designed to minimize "unforseen consequences" by separating data storage from data access.
MySQL still requires you to choose a particular (non-default!!) table type in order to have ACID
And with Oracle's purchase of InnoBase, maker of InnoDB, there is a reasonable chance that MySQL will end up dropping the InnoDB storage engine. After all, since InnoDB is GPL, MySQL AB only has a right to distribute InnoDB under a commercial license because of a contract with InnoBase. Here are the possible outcomes:
(1) Oracle renews the contract, and nobody worries until next time it comes up for renewal.
Unlikely. Why do you think Oracle bought InnoBase? Not to be nice, that's for sure.
(2) Oracle doesn't renew the contract, MySQL continues development, and drops it from their commercial version.
Approximately 0% chance of happening. What's in it for MySQL aside from the bad PR of having a commercial version worse than the GPL version?
(3) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL develops another storage engine.
Could happen. I have my doubts that would go very smoothly in the timeframe allowed. Most likely some functionality would change, breaking compatibility with existing InnoDB applications.
(4) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL doesn't develop another storage engine.
Seems likely, although they lose ACID and foreign keys, which are the most important "Enterprise" features of all.
So, it seems pretty much like #3 or #4, neither of which is good for the MySQL users. Expect MySQL AB to start preparing by warming up to BerkeleyDB to see if they can make that storage layer work. Expect MySQL AB to start spreading propoganda about how foreign keys and ACID really aren't necessary and only slow the database down (they can just un-rewrite some history and the propoganda is already there!). And expect them to try to make something out of SAP DB / MAX DB in a hurry. They'll try to get MySQL 5 out ASAP so that the impending problems with InnoDB don't take steam away from their release.
I am a big fan of PostgreSQL, but one thing needs to be set straight:
8.1 introduces "Constraint Exclusion" (CE) which is a very simple form of table partitioning. It is a good foot in the door, but it's far from a full implementation of table partitioning options. In fact, CE is not even enabled by default, because of some potential problems (although the problems seem far fetched and theoretical to me). Look forward to some more advances in the 8.2 release.
Couldn't Jonnie just take the buss to Nevada and buy the game there?
And concluded:
It seems to me that this law will be very ineffective.
My question is: how?
Whather the law is effective or not, your logic is lacking. Sounds more like a knee-jerk reaction opposing the general idea of government trying to protect kids from certain vices. There are, of course, ways to avoid enforcement, but it still may raise the bar, which may lead to a general reduction of usage of the games by minors.
I'm opposed to the "drug war", but it would be foolish to think that the enforcement doesn't reduce drug usage.
Slashdot, and other MySQL users should be concerned.
MySQL is centrally controlled and developed. That means that, unless the development model for MySQL changes, MySQL will need to take over development and maintainence of the InnoDB engine. Right now it would be a big change in the entire MySQL development model if the InnoDB engine were developed and controlled by some other group.
Also, this also sounds like it affects commercial licenses of MySQL, but I'm unclear on those details.
The license for InnoDB is up for renewel next year... guess that means that Oracle has a very strong position against MySQL. Maybe that's why MySQL is issuing press releases saying that they're not a competitor. MySQL may have to actually drop the InnoDB storage engine -- at Oracle's discretion.
Perhaps MySQL is saying "We aren't competing with Oracle" because Oracle has MySQL in a difficult position. Oracle just purchased InnoBase, the makers of InnoDB. They get to "renegotiate" the terms next year. MySQL may end up having to drop the InnoDB storage engine, and transactions along with it. After all, it's Oracle's option.
Re:No more than in any other computing environment
on
Sun Eyes PostgreSQL
·
· Score: 1
I understand what you're saying. Any turing complete system can do anything if you're willing to write a large enough layer on top of it to support the API you want.
When you already have a cross platform product which already implements many of the features you need at a high level, let's say "PostgreSQL" for example, why reimplement and API on top of it? It's just extra work, and extra bugs.
There are good reasons to do that sometimes, which you mention. When the layer below is not available on all the necessary platforms, for instance. I'm just saying it's not the answer to everything. Extra layers of abstractions have varying degrees of benefit, and varying degrees of cost. Benefits can come in the form of code reuse, reduced developer time, and fewer bugs. Costs can come in the form of code duplication, increased developer time, and more bugs. Often as you add one marginal level of abstraction, the marginal benefit goes down and the marginal cost goes up.
My main point is this: there is some threshold at which you decide that you have enough generalized abstractions already, and you need to use them to get your specific task done.
The newline issue that I think you're referring to was more an issue with Python than PostgreSQL. It seems that python was not properly interpreting the newline sequence when a chunk of code was written using one newline sequence and interpreted on a machine using a different newline sequence.
Notice I said chunk. Files work fine when moved between platforms. However, when calling the libraries to interpret embedded code (like PostgreSQL or anything that embeds python), python behaved a little strangely.
I like python, I use python, but to me the whole whitespace issue DOES cause problems. Take a look at ruby or perl, which can also be used in PostgreSQL, but behave better (in my opinion) as embedded languages. The ruby PL might be somewhat new or in development, but it's worth checking out.
Re:No more than in any other computing environment
on
Sun Eyes PostgreSQL
·
· Score: 1
But that is restricting yourself to the lowest common denominator. You need to program the functionality required for your application when the functionality already exists in another more suitable product.
You could say the same thing about filesystems: "Not everyone has a database, so we'll just program to use the filesystem and reinvent any functionality we need at that level.".
Worse yet, you're talking about reprogramming functionality for each subpar database you need to include in your list of supported databases.
As for your Java analogy, I think it's more accurate to say that doing what you're suggesting is like reimplementing the JVM before you start work on your project.
That's a good feature, and it will help many users.
However, I caution that constaint exclusion (CE) is a first step toward table partitioning. Those who assume that they can seamlessly split tables may encounter difficulty.
That only works if you want nothing more than the lowest common denominator from your database. Some people expect their database to do more than simple storage/retrieval.
Slashdot Mirror
A fork is possible. But what really needs to happen is the MySQL community needs to get it's act together and be independent of MySQL AB. There's a lot of community-building that needs to happen, because right now the whole development process is too dependent on MySQL AB.
This is not a fast process that a few good programmers can solve overnight. You need a few good programmers, a few good organizers, a few good decision makers, users involved on mailing lists, and a lot of time to figure out who does what and when they do it.
The project also needs direction. Will it be the same direction as when MySQL AB was calling the shots? If it changes direction, will the database cater to the same users?
Here's a potential problem I already see: You get all of the above requirements. Some of the decision makers think it's better to move in the direction of standards-compliance, strict error checking, consistency, and data integrity. The problem here is that they will always be chasing PostgreSQL, and their users will go elsewhere.
MySQL is kind of in a precarious position. If it gets "too good", it will compete with the likes of PostgreSQL and Oracle. They need to stay where they are, yet incrementally improve. It seems like any direction MySQL moves, the logical conclusion works against them.
But here's a great solution: mysql could use postgresql for its transaction layer.
An interesting point. One might wonder what it is that MySQL brings to the table if that happened though. Presumably, MySQL would bring nothing other than backwards compatibility with old applications. People would be jumping from MyGreSQL (or whatever this would be called) to the real PostgreSQL as fast as they could.
On the other hand...doesn't SQLite now support transactions & MVCC? And along these lines, could mysql pick up greater scalability by using db2 & oracle as storage layers as well?
MySQL has a commercial version to support. They can't charge someone a license fee and tell them to go elsewhere for a good storage engine. Anything in their GPL version needs to be in their commercial version. Therefore the only kind of code they can include is BSD-like, like PostgreSQL.
I guess they could have some kind of loosely-coupled interface that used another RDBMS as a backend, but again, what does MySQL provide? It would just be a SQL translator. It would be unable to optimize, plan, or execute queries, so that leaves what? Parsing? And then it's re-parsed by the other DB engine? That certainly won't impress anyone.
When a product gets to the point where it's ONLY possible value is backwards compatibility, people port the applications away quickly. [ insert MS Windows joke here * ]
* MS Windows doesn't really compare, since it's easy to replace a set of MySQL servers with a set of PostgreSQL servers, but not easy to replace a few hundred million installations of MS Windows.
The problem that people were having was how close the companies were getting. MySQL seemed proud to work closely with SCO, which was strange. Not necessarily bad, but some MySQL DB users are understandably concerned about the stability of MySQL AB.
The problem that MySQL DB is having right now is that it's too dependent on one company: MySQL AB. And that company is proving that it is not stable enough to count on.
If I were a MySQL DB user, I would be planning for an outcome that did not require MySQL AB, because the company might not be in the same form a year from now. Possibly even choose something else that has a stronger community behind it, or at least a stronger company behind it.
MySQL has a big community, but it's organized not around itself, but around MySQL AB. That may have to change.
You could be correct. I'm guessing that we'll all find out soon enough.
I think that MySQL will face huge problems because of this. It's damning that MySQL AB hasn't even spoken up about it.
It may be that there is some way for MySQL to get it's customers out of this mess. However, if I were a MySQL user, I would certainly be planning for the worst. After all, things look bad. It's almost certain that Oracle did this to quash MySQL, and they wouldn't spend the money if they didn't think it would succeed.
MySQL left itself vulnerable as a company. The MySQL user community left itself vulnerable by relying entirely on one company, with no real developers outside MySQL AB. It looks like it bit them.
The best alternative, should Oracle decide to refuse licensing or extort money from InnoDB licenses in the future, is to fork InnoDB and encourage community development.
That is the worst thing that MySQL AB can do. They would not be making any money from it because they couldn't sell it commercially. The commercial product would then be worse than the community version. And MySQL would have to live with the PR equivalent of a black eye.
That makes no more sense than Oracle supporting PostgreSQL development.
However, that may be good for the MySQL community. The community would have to restructure itself so that it wasn't based around a single commercial company. It would be tough to really progress for a while, but at least the existing users could be supported.
as there is a chance that the contract they signed causes them to lose all rights to sell InnoDB commercially when the contract expires.
I would assume that it's more than a chance. The contract is what gave them the right to sell InnoDB commercially in the first place. And it will expire next year. Therefore, unless it's renewed, they have no right to continue selling it.
However, if they were smart they would have had language in their contract that allows them perpetual commercial licenses to past versions
I doubt that InnoBase would allow MySQL AB to sell InnoDB commercially in perpetuity without additional royalties. That's absurd. That would effectively be like MySQL owning the copyright for themselves.
It makes no difference what the actual mechanism is.
That's because you don't actually have a mechanism. You have yet to give an example. You have yet to even really define what problem you're trying to solve.
I suspect that if there is anything of value along the lines of what you're talking about, it is already easily covered by triggers and listen/notify.
This is a very wrong-headed assertion. If you've got a requirement to individually process each of fifty million rows, which is better - pulling them all across the network to the client app, processing, then pushing them back to the DB, or doing the processing on the (big, powerful, local) DB?
Stored procedures are very important for many reasons, but you are making a wrong-headed decision as well. It's not about keeping logic in the database or keeping logic out of the database. What you need to do is put logic in the database if it maintains your data integrity or if it maintains the API you are providing to a client application.
A general rule is: if it's an inherent truth that has very little chance of changing over time, and it's consistent across all your applications, put it in the database and let the database enforce it. However, if it's just a current business rule that is subject to change, put it in the application.
They can't use their current commercial license with InnoDB unless the copyright holder of InnoDB code gives them permission. They can only distribute it as GPL, which would mean that any commercially-licensed code would be less featureful than the GPL version.
I doubt that MySQL will continue to pay for development on a product that they can't sell effectively.
But not ACID transactions or Foriegn keys, both of which are critical for any database trying to call itself "enterprise class".
The only storage engine that supports those things now belongs to MySQL's competitor. Not. Good. At. All.
This is not a well-thought-out feature at all. How is the database supposed to know what data an application *might* access? The database provides all the necessary isolation and notification systems. That's all it can do.
Also, how is the database supposed to notify the application? Would it throw an exception/error/warning/notice the next time you executed some SQL? Would it be a separate API call (in which case, why not just use LISTEN/NOTIFY)? Would it signal your process (thereby killing it if you don't have a handler)?
And the idea of "resolving" these dependencies would require a huge amount of knowledge that the database has no way of knowing.
I think you misunderstand the role of the database, and the relational model. The relational model is designed to minimize "unforseen consequences" by separating data storage from data access.
Silently truncating strings inserted into a varchar(x) field.
Allowing dates like Feb 31st.
Truncating numbers silently.
Strange NULL handling.
A lot more.
MySQL still requires you to choose a particular (non-default!!) table type in order to have ACID
And with Oracle's purchase of InnoBase, maker of InnoDB, there is a reasonable chance that MySQL will end up dropping the InnoDB storage engine. After all, since InnoDB is GPL, MySQL AB only has a right to distribute InnoDB under a commercial license because of a contract with InnoBase. Here are the possible outcomes:
(1) Oracle renews the contract, and nobody worries until next time it comes up for renewal.
Unlikely. Why do you think Oracle bought InnoBase? Not to be nice, that's for sure.
(2) Oracle doesn't renew the contract, MySQL continues development, and drops it from their commercial version.
Approximately 0% chance of happening. What's in it for MySQL aside from the bad PR of having a commercial version worse than the GPL version?
(3) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL develops another storage engine.
Could happen. I have my doubts that would go very smoothly in the timeframe allowed. Most likely some functionality would change, breaking compatibility with existing InnoDB applications.
(4) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL doesn't develop another storage engine.
Seems likely, although they lose ACID and foreign keys, which are the most important "Enterprise" features of all.
So, it seems pretty much like #3 or #4, neither of which is good for the MySQL users. Expect MySQL AB to start preparing by warming up to BerkeleyDB to see if they can make that storage layer work. Expect MySQL AB to start spreading propoganda about how foreign keys and ACID really aren't necessary and only slow the database down (they can just un-rewrite some history and the propoganda is already there!). And expect them to try to make something out of SAP DB / MAX DB in a hurry. They'll try to get MySQL 5 out ASAP so that the impending problems with InnoDB don't take steam away from their release.
I am a big fan of PostgreSQL, but one thing needs to be set straight:
8.1 introduces "Constraint Exclusion" (CE) which is a very simple form of table partitioning. It is a good foot in the door, but it's far from a full implementation of table partitioning options. In fact, CE is not even enabled by default, because of some potential problems (although the problems seem far fetched and theoretical to me). Look forward to some more advances in the 8.2 release.
You started with:
Couldn't Jonnie just take the buss to Nevada and buy the game there?
And concluded:
It seems to me that this law will be very ineffective.
My question is: how?
Whather the law is effective or not, your logic is lacking. Sounds more like a knee-jerk reaction opposing the general idea of government trying to protect kids from certain vices. There are, of course, ways to avoid enforcement, but it still may raise the bar, which may lead to a general reduction of usage of the games by minors.
I'm opposed to the "drug war", but it would be foolish to think that the enforcement doesn't reduce drug usage.
Slashdot, and other MySQL users should be concerned.
MySQL is centrally controlled and developed. That means that, unless the development model for MySQL changes, MySQL will need to take over development and maintainence of the InnoDB engine. Right now it would be a big change in the entire MySQL development model if the InnoDB engine were developed and controlled by some other group.
Also, this also sounds like it affects commercial licenses of MySQL, but I'm unclear on those details.
Here's the link for those interested:
n o.html
http://www.oracle.com/corporate/press/2005_oct/in
The license for InnoDB is up for renewel next year... guess that means that Oracle has a very strong position against MySQL. Maybe that's why MySQL is issuing press releases saying that they're not a competitor. MySQL may have to actually drop the InnoDB storage engine -- at Oracle's discretion.
http://www.oracle.com/corporate/press/2005_oct/inn o.html
Perhaps MySQL is saying "We aren't competing with Oracle" because Oracle has MySQL in a difficult position. Oracle just purchased InnoBase, the makers of InnoDB. They get to "renegotiate" the terms next year. MySQL may end up having to drop the InnoDB storage engine, and transactions along with it. After all, it's Oracle's option.
I understand what you're saying. Any turing complete system can do anything if you're willing to write a large enough layer on top of it to support the API you want.
When you already have a cross platform product which already implements many of the features you need at a high level, let's say "PostgreSQL" for example, why reimplement and API on top of it? It's just extra work, and extra bugs.
There are good reasons to do that sometimes, which you mention. When the layer below is not available on all the necessary platforms, for instance. I'm just saying it's not the answer to everything. Extra layers of abstractions have varying degrees of benefit, and varying degrees of cost. Benefits can come in the form of code reuse, reduced developer time, and fewer bugs. Costs can come in the form of code duplication, increased developer time, and more bugs. Often as you add one marginal level of abstraction, the marginal benefit goes down and the marginal cost goes up.
My main point is this: there is some threshold at which you decide that you have enough generalized abstractions already, and you need to use them to get your specific task done.
PostgreSQL is trying to centralize things at pgfoundry.org so these things should be a little easier to find.
Unfortunately, projects like pljava are still on gborg, which is an older system that they're moving away from.
The newline issue that I think you're referring to was more an issue with Python than PostgreSQL. It seems that python was not properly interpreting the newline sequence when a chunk of code was written using one newline sequence and interpreted on a machine using a different newline sequence.
Notice I said chunk. Files work fine when moved between platforms. However, when calling the libraries to interpret embedded code (like PostgreSQL or anything that embeds python), python behaved a little strangely.
I like python, I use python, but to me the whole whitespace issue DOES cause problems. Take a look at ruby or perl, which can also be used in PostgreSQL, but behave better (in my opinion) as embedded languages. The ruby PL might be somewhat new or in development, but it's worth checking out.
But that is restricting yourself to the lowest common denominator. You need to program the functionality required for your application when the functionality already exists in another more suitable product.
You could say the same thing about filesystems: "Not everyone has a database, so we'll just program to use the filesystem and reinvent any functionality we need at that level.".
Worse yet, you're talking about reprogramming functionality for each subpar database you need to include in your list of supported databases.
As for your Java analogy, I think it's more accurate to say that doing what you're suggesting is like reimplementing the JVM before you start work on your project.
That's a good feature, and it will help many users.
However, I caution that constaint exclusion (CE) is a first step toward table partitioning. Those who assume that they can seamlessly split tables may encounter difficulty.
have a database-independent wrapper...
That only works if you want nothing more than the lowest common denominator from your database. Some people expect their database to do more than simple storage/retrieval.