Based, on the other thread, it sounds like there is some interest in resurrecting the idea of a “universal Julia database API”. There are already some great Julia database packages, and thanks to ODBC.jl and JDBC.jl at least in principle we have everything covered, but currently there is no univers…

[image] dfdx: The whole point of having that many databases is that they are optimized for different things, and you just take the one that works best for your case. Speaking for myself at least, many times this is an “unfeature” and, as a practical matter at least, it gets in the way. Almos…

In particular, I think that Julia’s multiple dispatch, types, and traits could let us (even just for tabular and relational database access) could let us have a lot more commonality + ease of use, while allowing the full power of all the extensions that one (or more) databases might support. I don’…

[image] ExpandingMan: I agree in principle, but as a practical matter I just don’t know what to do right now to support lots of different types of databases, so you’d need to give us lots of impact to have much hope of that I think. If we go the PEP249 approach we can have something very soon. …

Ok, let’s bring it to the extreme: what’s the common subset of efficient operations supported by both - Aerospike and Vertica? Aerospike is a fast key-value database with possibility of data eviction when disk space reaches high watermark. It’s blazing fast for inserting and retrieving individual r…

[image] dfdx: My point is that you may have better time designing a good common API for SQL databases so that a user could: switch between equivalent DBs (e.g. MySQL <-> PostgreSQL or Vertica <-> Redshift) have a well-known interface integrated with the rest of Julia infrastructure. Yes, th…

[image] ExpandingMan: If we are happy with the PEP249 approach that would make things extremely simple, since we could primarily just resurrect DBAPI. That wouldn’t be that hard, I can probably do it in a few hours. :+1:

I think @randyzwitch got it exactly right: it would be great to have a simple package that handles the SQL case. All the other stuff can be parallel or on top of that. Some folks mentioned query translation from a higher level query language. Query.jl is designed to do that, the implementation is j…

Indeed one of the strengths of the tidyverse is that, as an user, it lets you do database things in a very abstract way. JuliaDB comes close (and will eventually be there), but not quite. I think this provides a good inspiration as to what the “universal” API may look like from an user perspective. …

Ok, I’ve done some digging around and investigating. I’ve done some very basic upgrading to 0.7 of DBAPI to make it a bit more easily readable, you can see this here . Also, here you can see what I had done when I modernized JDBC which was based on the previously existing DBAPI interface. Looking …

Hello. I think that something like ODBC/DBAPI is important to have, with a conceptually simple function: a universal adapter to tabular data sources. I say tabular, because you need to have some assumptions of the resulting data structure; and tabular structures are state-of-the-art and the 90% case…

Resurrecting universal database API

Specific Domains Data

Liso June 5, 2018, 3:31pm 26

Status of Julia database libraries

Topic		Replies	Views
Status of Julia database libraries General Usage	143	22078	October 23, 2024
A prototype for a minimalistic universal database API Data	4	770	August 20, 2018
Easiest and most complete package for PostgreSQL right now (Feb 2022)? General Usage postgresql	48	7756	July 11, 2025
Oracle DBI driver General Usage	38	5868	March 1, 2020
How do you store your data before and after processing with Julia? Data	35	7549	March 1, 2021

Resurrecting universal database API

Related topics