Design discussion

[iamed2]

Python DBI2 is not all that compelling -- it is a least likely to offend, erstwhile attempt at genericity. Times have changed some. I have no qualm with using it to make sure 'bases are covered'.

What is your opinion of SQLAlchemy (not that that should be the DBI -- that the DBI should allow such constructions (the Julia way) to become available with more ease and less expertise.

• @J-Sarnoff

I agree that Python's DB API 2.0 is not all that useful. This is certainly not an attempt to duplicate it :)

I love SQLAlchemy. I want DBAPI.jl to be the common interface which an SQLAlchemy could sit on top of. I also think there is room for a common dialect of SQL to speak to relational SQL databases, and that's somewhere I'd like to look in the future.

I also need to be able to talk about the data format I expect and have that format populated by this package with the fewest copies. One big downside of DB API 2.0 is that it returns data rows as tuples, in default data types defined by the database's data types. It is very common to want e.g. an array of columns of known types from a database, and necessary for some of my applications. I'm attempting to solve this by having both a simple row interface and a more complicated fetchinto_ interface both built by default on top of a single getindex method.

[J-Sarnoff]

Hadley Wickham's efforts to "tidy data" have been widely followed. Anything the DBI does that encourages this good principle will benefit our ecosystem. If you are not an R user, his work may be unfamiliar; here is the original paper http://vita.had.co.nz/papers/tidy-data.pdf.

[iamed2]

Thanks, I'll take a look at that later tonight.