On 10/9/11 7:28 AM, Piotr Szturmaj wrote:
1. I think that we should not design this API using the least common
denominator approach. This is to not limit some databases. For example
PostgreSQL has many great features not available in MySQL. That's why I
started with postgres in my ddb project. I think DB API should be
designed to support the most featureful databases and those that have
less features may be easily adapted to that API.
Some PostgreSQL vs MySQL differences to note:
- the former does support arrays and composite types that may be stored
in single column, the latter doesn't
Yah, Hive also has some really interesting data types, such as
parameterized arrays and maps and JSON data. Our API should be generic
enough to accommodate such types seamlessly.
- the former support asynchronous queries, but I guess its not that
important
- the former support async notifications (for example, fired by a
trigger, or when server is shutting down)
Not sure how we could support such. Ideas would be welcome.
2. Compile type mapping of fields should support postgres's composites
and arrays. For example, this is obvious:
execQuery!(int, string)("select 5, 'abc'");
but this is not:
execQuery!(int, string)("select ROW(5, 'abc')"); // valid postgres query
I think that should be
execQuery!(Tuple!(int, string))("select ROW(5, 'abc')");
Does it return two columns or one composite column? I already addressed
this ambiguities in ddb, please see documentation on github
(http://pszturmaj.github.com/ddb/db.html). See also 'advanced example'
on that page.
3. I think that compile type mapping of fields should be generalized to
not only support DB API. It could also be used with CSV files or other
tabular data. It may also be extended to support tree structures with
XML (mapping xml to structs/tuples/arrays).
Interesting.
Andrei
