[swift-server-dev] Database API/Framework

Helge Heß me at helgehess.eu
Wed Oct 26 05:26:51 CDT 2016

On 26 Oct 2016, at 11:34, Brent Royal-Gordon via swift-server-dev <swift-server-dev at swift.org> wrote:
> I'm not saying we should adopt DBI exactly as it is—Swift would demand a very different design. But I think we should consider using a similar architecture. It has a lot of advantages over forcing high-level frameworks to talk directly to low-level databases.

This is essentially the original message of the request, the desire to have a JDBC. Maybe people really want to have that :-) I guess a few protocols for simple use cases do not hurt, but I would advise against over designing this.

IMHO it doesn’t make that much sense since todays databases are so different. If you are a PostgreSQL user, you quite likely want to make use of its features (be it JSON columns, FTS, custom types, row permissions, table inheritance, etc).
Even pooling has very different requirements based on the setup of the database (e.g. in PG connections are pretty expensive, in others not at all, and SQLite doesn’t even have them). Let alone transactions and how they behave.
Presumably a HL framework has to have specific support to account for dealing with such differences, it can’t just rely on ‘JDBC'.

Personally I’m more interested in comprehensive interaction modules for the respective databases that can be used by all HL projects than in an API trying to bundle everything into a set of basic protocols. It is the HL project presenting a consistent API to the enduser (be it a full ORM or something more low level [e.g. I would rather stream batches of tuples coming from the database than building an EOF/CoreData like object graph]).

But I’m quite interested to see what proposals are coming in :-)


More information about the swift-server-dev mailing list