juliadatabases / dbapi.jl Goto Github PK

What the title says :)

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.

As described in https://discourse.julialang.org/t/ann-plans-for-removing-packages-that-do-not-yet-support-1-0-from-the-general-registry/ we are planning on removing packages that do not support 1.0 from the General registry. This package has been detected to not support 1.0 and is thus slated to be removed. The removal of packages from the registry will happen approximately a month after this issue is open.

To transition to the new Pkg system using Project.toml, see https://github.com/JuliaRegistries/Registrator.jl#transitioning-from-require-to-projecttoml.
To then tag a new version of the package, see https://github.com/JuliaRegistries/Registrator.jl#via-the-github-app.

If you believe this package has erroneously been detected as not supporting 1.0 or have any other questions, don't hesitate to discuss it here or in the thread linked at the top of this post.

Continuing discussion in this thread.

Initial point of discussion is what model to base a potential new database standard interface on. Examples include this package, existing interfaces for ODBC and LibPQ. Another intriguing possibility is embracing DataKnots.jl as a standard.

Here is a list of goals we should consider:

• A simple, uniform interface across all Julia database packages that allows users to query with any SQL string and dump into any DataStreams Sink.
• An unobtrusive design that makes it easy for users to use special features of individual packages that may not be universal (this is the one place where, if we are very careful, we might be able to offer something that sqlalchemy can’t).
• Simple for package maintainers to implement (at least the minimum features).
• Some level of compatibility with Spark, or at least carefully checking that this is feasible.
• A path toward ORM.

The tests in the Arrays category fail with the following error trace for each failed fact:

ERROR: MethodError: no method matching length(::DBAPI.ArrayInterfaces.ColumnarArrayRowIterator) # Could be ColumnIterator too
Closest candidates are:
  length(::SimpleVector) at essentials.jl:168
  length(::Base.MethodList) at reflection.jl:256
  length(::MethodTable) at reflection.jl:322
  ...
 in _similar_for at ./array.jl:262 [inlined]
 in _collect at ./array.jl:277 [inlined]
 in collect(::DBAPI.ArrayInterfaces.ColumnarArrayRowIterator) at ./array.jl:273

This isn't in an issue on v0.4, and tests pass there.

I checked the various methods defined for length and I found this one method that got defined in v0.4 but not in v0.5

length(cursor::DBAPI.ArrayInterfaces.ColumnarArrayCursor) at /Users/ranjan/.julia/v0.4/DBAPI/src/arrays.jl:107

I wonder if this is causing the issue.

It would be a nice low-level assist from the DBAPI to SELECT fields from the DB and, before returning the result, convert(TargetType, field)ing the field values to the types the queryor will use.

Can we put this package in METADATA? We've been trying use this API in JDBC.jl. I think this is stable enough to implement now...

cc: @ViralBShah

https://github.com/JuliaDB/DBAPI.jl shows Builds Failing
whereas
https://pkg.julialang.org/detail/DBAPI.html shows: Julia v0.6: 0.1.0 (a month ago) / Tests pass.
Which is it?

Hello, currently the interface provided by this package is useful in JDBC. Since this package seems largely abandoned, I'm wondering if it should just be folded into JDBC. Either way, I'd like to make a PR tomorrow to update it to work without warnings or errors on 0.6 and 0.7.