MySQL Upgrades

[0ddb411]

When are we going to get MySQL 5.0/5.1?

They have been around for some time now.

--> Josh

[paulredpath]

Josh,

We dont have any plans at the moment to support Mysql 5, it's not as tested as the 4.x and may break some applications due to differing behaviour. We don't feel that it's stable enough to implement for a large number of applications yet.

[0ddb411]

Makes sense I guess... *mutters about reasonable people being so unreasonable*

Ok - if I can't have my MySql 5.0, what about SQL Server 2005? Come to think of it, that must cost one hell of a lot of money - I guess we're going to wait on that one too

I'm off to the database forum to try and get some help on a cyclic foreign key problem.

ta ta

[paulredpath]

SQL 2005 is imminent, just about to order up the server end of the month once we finish a few other upgrades.

[schestowitz]

MySQL version 5 would break parts of my site...

Sorry...

[0ddb411]

Any news on the SQL Server 2005 upgrade, Paul?

I'm about to actually use a MS SQL database for the first time in my life (whadooidoowhadooidoowhatdoidoo) and I'd be really depressed if I write a natty bit of code for my aged SQL 2000 setup and it didn't port

Are we going to get free upgrades on our reseller packages to 2005 - will all 2000 servers be upgraded.

Oooh -it's like Christmas, isn't it

[paulredpath]

We are still sorting out a few bits and pieces but you should see sql 2005 appear shortly

[0ddb411]

Briging up an old point - old wounds as it were.

MySQL 5.0 has been in release since October 2005. How much more testing does it require before you will update your servers?

I know some of the applications people have will break, but that's not a reason to not upgrade. Give a month or two notice and get it done! Before I cry.

People should embrace, not fear, new technology. If it makes them alter their code - well, it probably needs a brush up anyway.

--> 0ddb411

[0ddb411]

I don't normally do this. I think it's deplorable, dispicable and evil.

However.

Bump.

[rob]

Hi,

Unfortunately, although you may see upgrading to MySQL 5 as something that people should 'have to work around', this isn't really the opinion that is held by the majority of our customers. I agree that often people do not want to upgrade just for their own convenience, but in many cases, external developers are hired for a site to be written, and the change is incurring additional expense to a number of our customers.

What is the requirement that you have specifically for MySQL 5? I know that when we've asked this in the past, some people have merely said that it is 'the latest version'! We use packages that are supplied by Redhat, and are hence supported packages - bugs that we find can be dealt with by a team of developers to fix it. If we deviate from these versions then bugs, which may affect /all/ users - not just those who wanted a change, become much more difficult to get solved.

Unfortunately, when you're paying 50-75 GBP per hour for your developer - "well, your code needed updating anyway" doesn't really fly, and if you can blame your hosting company for the change, then this is often a reason to move. We run our servers in order to allow maximum compatibility with the features that we've offered in the past, and hence allow those sites that are hosted with us to operate as smoothly, and reliably as possible. Changes of a large nature are generally made when there's a justifiable requirement to do so.

cPanel also has a problem that it operates database server instances on a per server basis, and hence we can't add a MySQL 5 server for multiple servers, and allow control of it through cPanel. There simply isn't enough demand for MySQL 5 to justify a dedicated MySQL 5 server for it.

If you've got any questions relating to this, please feel free to drop me an email personally, and I'd be happy to discuss it with you.

Thanks,
Rob

[0ddb411]

My primary reasons for wanting MySQL 5 are:

- Stored Procedures
I'm writing and building application on a regular basis where I have to replicate SQL code due to scope or protection issues with the internal class structure of my project. Stored Procedures would allow me to minimise my dBase round-trips and required connections by allowing me to script recursive, hierachical or repetative tasks on the data server. One round trip available to every level of my application.

- Table metadata accessible from SQL (INFORMATION_SCHEMA) rather than SHOW statements
MySQL's SHOW statements are wonderful - but they really don't allow my to access the full range of meta-data available to me simply. Part of the design process of a good data system is knowing when you don't need to query the dBase. Caching is easy to implement when you dBase can give you a clear, consice and accurate idea of the last time a table was updated. This functionality has been added in MySQL 5

- Triggers
I only use triggers for one thing, I'm sure they have more uses but I've never come across one. I use Triggers for updating self-referential foreign keys (keys that reference their own table). By default I can not specify a cascade delete on these FKs because MySQL (and MS SQL) are morbidly afraid of a run-away delete scenario. Triggers allow me to overcome the mollycodling and ensure FK integrity in self referential tuples.

- Better support for nested queries
I can't begin to tell you how important nested queries are to a developer. You should know. Not being able to use them to their full extent is cripling. Almost as bad as...

- Updateable Views
Not being able to use Views properly! What a pain in the ahem.

Apparently it does a whole shead load more stuff too, but that's all I want. And I want it to recognise the SQL I've written to date, rather than having to re-write it all into T-SQL.

I love you guys; you're fast, curtious, run a tight ship and never let us down but I'm just not going to be able to deploy my next generation of applications on your servers - nor do I want to cripple my development activities because you're afraid to make a bit more money for a few developers.

I'm going to sound like my grandad here, but if we were worried about putting breeders out of business we'd all be riding horses. Times change - sooner or later your support for 4 will be dropped, as will all the people who didn't look into trading up sooner - straight into the frying pan.

[rob]

Cool - it's good to see that there's actually a requirement for MySQL 5. Not meaning to cause any offense at all, but some requests that we receive for features seem to be focussed around "bigger numbers are better!".

I think you misunderstood my point about people paying developers to update their code. Look at it from a business point of view. You've written your site to work in X technology as that was your current platform at the time, it works fine, and continues to work fine. You've probably put a lot of capital into getting it developed and integrated with your payment gateways and other third-party components that you've required. From your perspective, there is no need to change. However, if I then change the server that your site is hosted on, I'm costing you a large amount of money, which you probably didn't budget, to go away and find your developer and get it fixed up.

However, it's not just the money side of things.

We changed our Linux servers over to using phpsuexec, and this caused some sites to break. We ended up having a few customers who had completely non-operational sites due to this change. Now, it's difficult here to know what to do - do we deploy our staff time to get these sites fixed? Or, as you seem to be suggesting, tell people that it's their problem - fix it! There's no right and wrong answer here, I think, there are pros and cons for both sides. Yes, running current versions is good, as long as they have undergone QA, and are supported.

At the current time, our Linux boxes are RHEL based. We're running on RHEL4, since that's the latest that cPanel supports right now. In RHEL4, MySQL4 is shipped.

Now, some good news for you. RHEL5, which we're now testing, and waiting for cPanel to release a compatible control panel for ships with MySQL5.

[root@grapefruit ~]# yum list | grep mysql-server
mysql-server.i386 5.0.22-2.1 rhel-i386-server

From testing RHEL5, I'm pretty happy it's going to be stable enough to deploy when we roll a new Linux machine - it'll be running MySQL5. According to our capacity planning, we'll be deploying that machine in the next couple of months (depending on cPanel).

If your requirement is more urgent than that, can you drop me a mail, and I'll see what I can come up with in the short-term.

Cheers,
Rob

[0ddb411]

you're fast, curtious, run a tight ship and never let us down

See what I mean? :P

My first application rollout will be in a month or two but will almost certainly require a dedicated server so there's no problems there. I made sure I got my whining in eairly to give this sort of thing time

If it's on the cards then it's on the cards - I can't ask more than that. I'm going to continue to develop for my internal MySQL 5 dBase and hi-jack my clients dedicated server database space until such time as you folks roll out '5.

This is why I recomend you to all my friends.

One other thing - I'm a .net developer so it's HELM for me all the way! This is where I find out that HELM isn't ever going to support MySQL 5...

[paulredpath]

HELM will support MySQL5 databases shortly as well

[rob]

Hi,

MySQL5 has now been added to HELM packages as an additional feature.

Enjoy,
Rob