Issue Type: Bug Created: 2008-04-21T03:14:09.000+0000 Last Updated: 2009-09-20T14:55:35.000+0000 Status: Resolved Fix version(s): Reporter: Ben Gray (ben) Assignee: Jesse Lesperance (jlesperance) Tags: - Zend_Db
Related issues: - ZF-5606
Lines 239 and 240 of Zend_DB are:
$adapterName = strtolower($adapterNamespace . '_' . $adapter); $adapterName = str_replace(' ', '_', ucwords(str_replace('_', ' ', $adapterName)));
This means that any database adapter that isn't in a camel case path structure cannot be loaded by the system. In most cases this isn't a problem however recently I worked on a project when there company initials where used as all upper case as their framework name.
As this is perfectly valid within PHP I think that the fact everything is strtolowered then ucworded is a bug or at the very least an annoyance that should be altered.
The workaround I'm currently using (and why this is only minor) is to symlink with the required case version. The autoloader is happy to load the class despite the case differences to the classname as function names, and so classnames, are case insensitive.
Posted by Ralph Schindler (ralph) on 2008-07-19T10:00:55.000+0000
At current, this is not necessarily a bug. In fact, it is inline with the current coding standard on class & method nameing conventions. While this will be discussed within the next few months, it is important to know that the current coding standard states that Classes and Methods should NOT maintain their acronyms as all caps. Instead, acronyms should simply be treated as "Words" and proper care should be taken to only Cap "words" within a name to indicate word-separation.
So something like SomeXmlNode is correct, where SomeXMLNode is incorrect. If you were to translate this to a different word-separation scheme (like dashed lower), then you would be the correct version of "some-xml-node". The incorrect version would read as: "some-x-m-l-node".
We will discuss in the near future our stance on acronyms and camelCasing rules. But in the mean time, this is correct behavior for the current naming standard.
Posted by Luiz Fernando Furtado (kgbfernando) on 2008-11-20T17:52:14.000+0000
The current naming standard don't permite use with ZF extras, like ZendX_Db_Firebird.
The extras broken the naming standard with the "ZendX" prefix and the code must be changed to reflect this.
Do this broke BC? If the developer used a AdapterNamespace with diferent case from the real file/class name, YES.
One solution (I think not the best) is to add after line 247 (v1.7.0) the folowing line:
@Zend_Loader::loadClass($adapterNamespace . '_' . $adapter);
Posted by Ashley Kitson (akzincdig) on 2009-09-18T06:02:28.000+0000
Still broken in 1.8.2
My app prefix is UUllll_ (i.e. 2 upper case characters followed by lowercase ones.)
Everywhere that I use it with what is now quite a large ZF based system, there are no problems. I recently had to write a variant of the pdo_mysql adapter to get around the problem of the describeTable() not bringing back UNIQUE column info . Following the ZF documentation, I amended the creation of the adapter to add the adapterName
$params['adapterNamespace'] = 'ZWare_Object_Db_Adapter';
Doesn't work. Gets converted to Zware_Object_Db_Adapter and of course falls over.
1/ the documentation is incorrect. It explicitly shows a mixed case example name 2/ This is out of line with the rest of ZF, despite the above comments on 'the coding standard'
There is a work-around. You simply have to catch the adapter type you want to instantiate and do it directly instead of using the factory class if you need to use your own instead of the Zend one. Not very elegant, but it works. I agree with other commentators, This shouldn't be necessary.
Posted by Ralph Schindler (ralph) on 2009-09-20T14:55:35.000+0000
Fixed with solution for ZF-5606
Have you found an issue?
See the Overview section for more details.