Add capability information to the drivers

[Skarsnik]

We probably want to add a way to have information about what the driver can support or how he handle different thing. It will make writing Test better.

Example:

-Typed NULL result or not, SQLITE Null value are untyped (well, they are typed Null) when other drivers give you the type of the field -Array support or not (it's in sql rfc), Pg support then, other not

It will probably replace the $sth.can('method') in the test suite too.

[abraxxa]

Yes, I was thinking about the same thing! I'd use roles to signal supported features, does that make sense?

[Skarsnik]

A hash could be enought, roles sound really overkill/weird if you imagine a lot of then.

Here some list of capabilities (ideas)

has-rat-precision - to tell if the drivers handle more than Float (P6 Num) for no integer number has-read-array - the drivers can return Array field as p6 Array has-bind-array - the drivers can bind Array in prepare query has-typed-null - the drivers still provide type information for null/empty field

[salortiz]

I like the idea. In fact I now use a hardcoded typed-nulls => False in "t/40-SQLite-common.t" I think that a simple method capabilites at the driver level can be enough.

Are you thinking in only Boolean capabilities?

[Skarsnik]

I think it's more what use case we have to cover. (that why I listed some) There are probably stuff like how empty/null field are handled (I think I remember some driver that differenciate null and empty and other not)

[salortiz]

Well, a concrete use case is in Test::DBDish. Now we have three drivers that returns typed NULLs and SQLite that can't.

The test suite now adapts the related tests to test both cases, the default is typed-nulls = True so we need a way to, after loading the required driver, interrogate it and change, if needed, that default.

I can think of several possible implementations. But first I have a few questions:

• We want that all drivers must report all capabilities, even the common ones?
• We want to report the capabilities of the underlying DBMS, only of the current DBDish driver or both?
• Or only the exceptions to the common rules?
• What is the expected set of that "common" rules?

Perl5 DBI uses $dbh->get_info(CAP) as a generic mechanism based on ANSI/ODBC standards.

For exceptional capabilities, thought that opt-in / opt-out separated tests can be now, a better idea.