Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.5.0b5

Bug #12269 tableInfo() does not detect 'clob' data type
Submitted: 2007-10-17 20:59 UTC
From: mthorslund Assigned: quipo
Status: Closed Package: MDB2 (version 2.4.1)
PHP Version: 5.2.1 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2007-10-17 20:59 UTC] mthorslund (Mattias Thorslund)
Description: ------------ Hi, I am using the tableInfo() function of the Reverse module in order to detect whether a table needs to be altered or not. This is great functionality, very useful. My problem is that tableInfo() does not return the same MDB2 data type as I used when defining the column, in the case of 'clob'. This causes my script to flag a table change when in reality nothing changed in the table structure. The underlying MDB2_Driver_Datatype_mysql::_mapNativeDatatype() method returns the data type as an array containing 'text' and 'clob', which is forwarded through MDB2_Driver_Reverse_mysql::getTableFieldDefinition() as an array of two definitions: One with the mdb2type as 'text' and one with the mdb2type as 'clob'. The MDB2_Driver_Reverse_Common::tableInfo() function then ignores the second definition and uses the first one. In order to avoid this issue, I've hacked the line (in MDB2_Driver_Reverse_Common::tableInfo()) which reads: $res[$i] = $definition[0]; into: $res[$i] = end($definition); I don't know if this change causes any other problem but it seems to work for me. If there are no other complications from this, I'd like to suggest that as a patch. Mattias Thorslund Test script: --------------- Conceptual, not tested: //define a field with the $definition = array ( 'description' => array ( 'type' => 'clob' ) ); $mdb2->createTable('test', $definition); //now check the table: $table_info = $mdb2->tableInfo('test', NULL); print_r($table_info); Expected result: ---------------- Array ( [notnull] => [nativetype] => longtext [fixed] => [type] => clob [mdb2type] => clob ) Actual result: -------------- Array ( [notnull] => [nativetype] => longtext [fixed] => [default] => [type] => text [mdb2type] => text )

Comments

 [2007-10-22 20:35 UTC] quipo (Lorenzo Alberton)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.
 [2008-04-16 16:17 UTC] nrf (Nathan Fredrickson)
The same patch that resolved this ticket was previously added and removed. Added in May 2006 http://cvs.php.net/viewcvs.cgi/pear/MDB2/MDB2/Driver/Datatype/pgsql.php?r1=1.58&r2=1.59 And then removed in June 2006 http://cvs.php.net/viewcvs.cgi/pear/MDB2/MDB2/Driver/Datatype/pgsql.php?r1=1.64&r2=1.65 Here was the discussion at the time: Nathan Fredrickson wrote: I have a problem with a recent change made to the pgsql Datatype driver. In revision 1.59 of Datatype/pgsql.php [1] a call to array_reverse() was added. When the native type is 'text', this causes the $types array to to be reversed from array('text', 'clob') to array('clob', 'text'). Since the result introspection uses the first type in the array, 'clob' is used instead of 'text'. Lukas wrote: I presume this breaks your runtime introspection? I am not dead set on forcing this change. I guess a lot of people are just using TEXT as a very large VARCHAR and not as a LOB .. Nathan Fredrickson wrote: Exactly, we're using TEXT as a large VARCHAR and this breaks runtime introspection. I have no idea which usage of TEXT is more common, but I'd prefer to see this changed back so that MDB2 type 'text' comes first. Lukas wrote: OK, I guess we can do that.
 [2008-05-13 17:26 UTC] quipo (Lorenzo Alberton)
Hi Nathan, as you know there's no way of knowing what was the MDB2 data type used to create the column (text or clob), so it's just guesswork. Which one should have priority? You and Mattias seem to have different opinions... I'm not really partial to any solution, even if I think that 'clob' is theoretically more appropriate (according to MDB2 intentions) for big text fields, where "big" means "without a specified length". So, whom should I listen to? ;-)