Is there any work being done to provide a database independent API that higher level frameworks could be built upon?
I'm thinking of something like the JDBC API but for Swift, where all you need is the driver from your database vendor and you are up and running.
The driver could use the database vendor's native libraries. It could also be written in Swift on top of SwiftNIO.
The library could be called SDBC, or SwiftDBC, or SwiftDB, but would require a driver to actually connect and talk to a specific database.
I've seen some activity in drivers being written using SwiftNIO. That is great start but I think a unified API would be highly beneficial to developers and open the door to the creation of very cool and powerful higher level frameworks.
For example, a database independent object to relational mapping similar to Apple's Enterprise Objects Framework included in the good/old/awesome/end-of-lifed WebObjects product.
It's really odd to me that many years ago Apple had the Enterprise Objects Framework (EOF) ported to java and used JDBC to connect to all kinds of databases.
Swift is a beautiful and elegant language but it's totally lacking database connectivity on the server. :-(
Swift is a beautiful and elegant language but it's totally lacking database connectivity on the server.
I agree. The Swift server work group is currently prioritizing work on database driver packages. We've made a lot of progress on this so far, but there are many more to cover. Creating good driver packages is the key to creating good, higher level packages.
As always, if anyone is interested in helping create a new database driver package we'd be more than happy to help you get a pitch going.
That is great start but I think a unified API would be highly beneficial to developers and open the door to the creation of very cool and powerful higher level frameworks.
I agree this could be useful eventually, but I think we are still too early days to make a big decision like this. There are a lot of great features yet to come in Swift that could have a large impact on how such an API is designed. There's also a ton of ways such a library could look. As @esummers's mentioned, there are a few existing database APIs in Swift already. Two I've created at least are:
But there are a lot more than just those. There's also a plethora of client-side database libraries in Swift that have been used for iOS and macOS development. We should first strive to understand and discuss the possible solutions before we agree on a unified API. We should also prioritize building on Swift's strengths. Learning from the success of something like JDBC is obviously great but we shouldn't assume something that works well in Java would also work well in Swift without strong evidence.
That said, exploring JDBC's design in a Swift package could be very useful. It might end up working out extremely well and be a model for how things should work in Swift. We won't know until we test it.
Finally someone is remembering WO/EOF. I had a short intermezzo with Fluent when developing a simple backend for one of our iOS-apps, only to find out that Fluent is still missing quite some features EOF-users take for granted (like "propagates primary key" and "owns destination" or "compound primary keys" for join tables (which shouldn't sport an independent primary key otherwise multiple many to many relations are possible database-wise)). I then talked to some Fluent-Developer. To my surprise he had never even heard of WebObjects or the Enterprise Objects Framework …
ZeeQL is my EOF for Swift, it support most of what GETobjects did on the modeling level (proper relationship queries etc) but it lacks a little due to the missing reflection capabilities of Swift.
However, what would be useful first is the mentioned JDBC level of interop (the EOAdaptor layer in EOF terms).
Or even something simpler, like generalized pooling for NIO connections.
