requiring char_set and dbcollat?

[eluser]kandmcreative[/eluser]
In 1.6.1, it appears that $char_set and $dbcollat is required in the db config, but most db drivers don't require it.

Instead of adding it to my database config file, and breaking 1.5.x installs, would it be best to add them to DB_driver.php?

Lines 58 - 61:

Code:

var $cache_autodel    = FALSE;
    var $char_set    = FALSE;
    var $dbcollat    = FALSE;
    var $CACHE; // The cache class object

[eluser]Derek Jones[/eluser]
No, as that would require someone to modify that file for every installation, file refresh, upgrade, etc. Drivers that don't use it aren't harmed by its inclusion, and in the future other drivers will support it as well.

[eluser]kandmcreative[/eluser]
Without adding that code, using the mssql driver, I get this error:

Code:

A PHP Error was encountered

Severity: Notice

Message: Undefined property: CI_DB_mssql_driver::$dbcollat

Filename: database/DB_driver.php

Line Number: 177

To remedy the error, i can fix it in the system, or go into each project that uses the system (I have 6 sub-sites looking at one system) and add some dummy parameters to config/database.php. Are we expecting users to have $dbcollat and $db_charset always set in their app/config/database.php?

Thanks,
Kevin

[eluser]Derek Jones[/eluser]

Are we expecting users to have $dbcollat and $db_charset always set in their app/config/database.php?

Yes, as step 4 of the update instructions for 1.6 indicate. These two settings are no different from the other settings in database.php. If your driver does not yet implement them, you can leave them empty, but from here on out, CodeIgniter will expect those variables to exist in your database.php file.

[eluser]tonanbarbarian[/eluser]
i have already suggested some changes so that if the dbcollat and db_charset are NULL then the database libraries do not attempt to set them.

[eluser]Derek Jones[/eluser]
tonanbarbarian, are there specific drivers that do not support setting the client character set? I have not had time to investigate them all with our current development schedules, which is why 1.6 leaves those drivers with a return TRUE; in that method. Unless there is more than one driver that doesn't support this in any shape or form, it is not likely that we will incorporate the behavior you suggest. For MySQL users, as I've mentioned, future features will continue to require version 4.1+. This is a minimum requirement for many planned features down the road for that driver, so making that change for the sake of older MySQL compatibility will not take place.

[eluser]tonanbarbarian[/eluser]
i can understand the reason why you did what you did with mysql 4.1 etc

i am not sure if there are other issues with other drivers re char_set

[eluser]tonanbarbarian[/eluser]
one minor criticism tho
i was not aware that mysql 3/4.0 was no longer supported until these threads came it
it might have been nice if in the 1.6.0 changelog it stated something like
- MySQL Support 4.1+ only from now on
or something similar

I know the userguide was updated so that the requirements now say 4.1, however when i have been using software for a while i tend to only look at changelogs when a new version comes out. My fault I know but still some warning in the changelog would have been nice

I currently host a server with mysql 4.0 on it, and while it will be upgraded within a few months for now I have to hack the driver to get it to work

Can I ask what future features are going to requires 4.1?
because for me as a software developer one of the things I loved about ci was it did not limit you, and now it does
if i build software I have to say mysql4.1+ (yes i know there are probably only a statistically small number of servers still running mysql less than 4.1)

[eluser]xwero[/eluser]
I'm for a backward compatibility too considering it's only a minor adjustment.

I can only speak about the situation in Belgium but hosts tend to stick to proven technology even when there are security risks involved.

I think the compatibility issue makes the need for extended database methods more noticeable.

[eluser]Derek Jones[/eluser]
Point noted, tonan, and I'll make sure it gets added to the Change Log. For your other questions, I'll direct you to this post.

I think the compatibility issue makes the need for extended database methods more noticeable.

That's not necessary - if you want legacy MySQL support, you can simply copy the existing MySQL driver to a newly named folder, change the db_set_charset() method to return TRUE, and maintain the legacy driver file. Since 4.0's lifecycle doesn't officially end until December of this year, that might be something we'd be willing to drop into the svn.