I don't think we'd probably care a tremendous amount one way or the
other, although camel case certainly makes things a lot easier to
read.

Certainly the length of table names is more problematic as it
eliminates some potential database compatibility (ie: oracle)

The real challenge is with several hundred add-ons out there, its
going to be very very hard to effect massive changes to the database
approach. One would have to weigh benefits against the significant
pain...
best wishes

Franz Maruna
CEO - concrete5.org
http://about.me/frz

Good Day Franz,
Thanks for the notes. I have a question as a datacenter that I use and brought up a new instance last week after moving it from QA, it is live now and I was testing recovery by pulling the production back to QA ... Now the QA does not work and looks like the structure was mixed case in production and the export came back to QA as all lower case.

As production went live and it looks like the original push (and now updates that have been created in production ) are now locked into a lower case structure.

At this point I would like a couple of elements of feedback:

1) Given the production environment is currently lower case, will that cause issues for future upgrades? IS there a way around if so?

2) Is there a way to get the table case back (camel case you note) without losing the production site? That is, is there a method to get all the content out , create the correctly-cased structure and reintroduce the content without making a terrible mess?

3) Does it matter? If production is now locked into lower case do I just accept I was whacked by this (really wish people knew that 'This' and 'this' are unique ...) and move on?

Do I need to provide more details, does this all make sense?

Thanks in advance for any/all applicable feedback.

You have a few options.

1. You can ignore it. Since everything seems to be working ok and you're probably only going to go from a Case Sensitive System to a Case Insensitive system, this might be ok. If you ever need to go back from production to Mac or Linux, you'll have problems.

2. You can fix the table names.

a. Set the lower_case_table_names setting as described here:

http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity....

You'll want to set it to use lower_case_table_names=0 on Unix and lower_case_table_names=2 on Windows

b. You can go through all tables in your database and fix the table case names to their original values. You can do this manually (which is painful but probably not more than 15 minutes of work.) Or you can use this add-on:

http://www.concrete5.org/marketplace/addons/mysql-case-insensitive-...

Note: we have tested this add-on with a basic installation of concrete5 at the time of accepting it, but you'll want to run this on a staging site before running it on production. THIS IS STRONGLY ADVISED. I would not run this on production before testing it extensively.

Andrew -- thanks.

Let me digest all of this. Good to know #1 should not be an issue.

What about C5 upgrades? Will new versions of the CMS framework and upgrade process (note I am not sure at this time how that is managed but will likely need to at some point) have issues with the production lower case state? Or will the way that system is configured result it that not being an issue?

I hope the rest of your day goes well.

I believe that you shouldn't have any issues upgrading the tables on a case insensitive file system in the future. I know that I get weird behavior when I reference tables that are cased differently on my OS X system – but that's a different setup than yours.

I'd personally opt to fix the case with option 2 but I really don't think that, on Windows, you're going to have a problem unless you try and go from Windows back to Linux/OS X. (Someone else feel free to chime in on this point if you understand it differently, my knowledge of MySQLs case sensitivity troubleshooting on Windows is somewhat limited.)

Andrew,

I am good with the table changes as well. I will need to plan that for off peak time since it is production. I may, if that is OK, post the SQL for review here when I have that created.

By design it is not windoze in any of my environments. My platform and my mind/methods/etc. are case-sensitive. I am on a new contract and stumbled on this when I wanted to create QA (did not exist before) and thought I would do a quick sync with what was production. I figure there are a few ways to wiggle out of this. I appreciate your responses.

what about some way to refresh the site db.xml, package db.xml's and block db.xml's? that should fix the case shouldn't it?