Re: $db->tableInfo(); (PEAR::DB)

cox@idecnet.com (Tomas V.V.Cox) wrote in <3BA1153B.53B30DB8@idecnet.com>: >IMHO the tableinfo methods are perhaps the most difficult things to get >and abstract. And yes it could be nice if we could abstract flags, types >and lengths (for ex. postgres returns -1 in a text field type that means >1Gb if I'm not wrong). > >Please go ahead with your suggestions :-) You are right, this wont be easy, but we could start to abstract the basic flags like "primary_key", "foreign_key", "int", "char" and so on. I know there would be a loss of information (for instance pgsql has a type called int8 or int4), but there should be the chance to get the abstracted version of flags _or_ the original flags. This way, one can get int8 if he really needs this information, but in an abstracted world, it should be enough to get int. You cant write dababase management programs with the abstracted version, but the abstraction is IMO mainly intended to DB based applications. For them its enough to know that a field is an INT. But again, you could also get the original flags then. Please take a look at JDBC, its the same there, all implementors of JDBC drivers map db types to JDBC types(which in fact seems to be ansi sql92 types or?). So perhaps all implementors of PEAR:DB db-abstractions like mysql.php or pgsql.php had to implement also a defined schema. [from the sourcecode of MM Mysql JDBC driver] case MysqlDefs.FIELD_TYPE_DECIMAL : sql_type = Types.DECIMAL; case MysqlDefs.FIELD_TYPE_TINY : sql_type = Types.TINYINT; case MysqlDefs.FIELD_TYPE_SHORT : sql_type = Types.SMALLINT; case MysqlDefs.FIELD_TYPE_LONG : sql_type = Types.INTEGER; case MysqlDefs.FIELD_TYPE_FLOAT : sql_type = Types.FLOAT; case MysqlDefs.FIELD_TYPE_DOUBLE : sql_type = Types.DOUBLE; case MysqlDefs.FIELD_TYPE_NULL : sql_type = Types.NULL; case MysqlDefs.FIELD_TYPE_TIMESTAMP : sql_type = Types.TIMESTAMP; case MysqlDefs.FIELD_TYPE_LONGLONG : sql_type = Types.BIGINT; case MysqlDefs.FIELD_TYPE_INT24 : sql_type = Types.INTEGER; case MysqlDefs.FIELD_TYPE_DATE : sql_type = Types.DATE; case MysqlDefs.FIELD_TYPE_TIME : sql_type = Types.TIME; case MysqlDefs.FIELD_TYPE_DATETIME : sql_type = Types.TIMESTAMP; case MysqlDefs.FIELD_TYPE_YEAR : sql_type = Types.DATE; case MysqlDefs.FIELD_TYPE_NEWDATE : sql_type = Types.DATE; case MysqlDefs.FIELD_TYPE_ENUM : sql_type = Types.CHAR; case MysqlDefs.FIELD_TYPE_SET : sql_type = Types.CHAR; case MysqlDefs.FIELD_TYPE_TINY_BLOB : sql_type = Types.VARBINARY; case MysqlDefs.FIELD_TYPE_MEDIUM_BLOB : sql_type = Types.LONGVARBINARY; case MysqlDefs.FIELD_TYPE_LONG_BLOB : sql_type = Types.LONGVARBINARY; case MysqlDefs.FIELD_TYPE_BLOB : sql_type = Types.LONGVARBINARY; case MysqlDefs.FIELD_TYPE_VAR_STRING : sql_type = Types.VARCHAR; case MysqlDefs.FIELD_TYPE_STRING : sql_type = Types.CHAR; on the left you have the mysql types and on the right the JDBC ones. Perhaps we could map to the same types as JDBC, because JDBC has proven some kind of success in abstracting DB. Then we had to go on with things like keys.... comments? -- Marc Logemann (aka Loge, www.marc-logemann.de)