[swift-server-dev] Database API/Framework

[Ron Olson]

I mentioned JDBC because I happened to be looking at some Java code at 
the time, but I really meant 'generic-interface' to provide the 
lowest-level-but-no-lower-than-necessary access to the database, 
regardless of whether it was sqlite or postgres. I think Go does a 
pretty good job of providing that thin layer of abstraction and it's up 
the driver writer to implement. After that what somebody wants to do 
with the results is their business.

Personally I don't like ORM layers; most of the time I'm writing complex 
queries that don't fit neatly into an ORM paradigm and I end up fighting 
with the framework.

Ron

On 25 Oct 2016, at 15:44, Helge Heß via swift-server-dev wrote:

> Hi,
>
> On 25 Oct 2016, at 21:34, Haris Amin <aminharis7 at gmail.com> wrote:
>> So I’m currently working on a pure Swift Postgres driver.
>
> nice, I’m working on one as well (currently can run only basic 
> queries, nothing fancy).
>
>> 1. A standard socket api, there are a few right now. Currently I’m 
>> using IBM’s BlueSocket but really we just need one socket api that 
>> works cross platform.
>
> I would be interested what people are really missing here (at that 
> basic level). GCD channels are really quite nice for that kind of 
> stuff (scheduling IO) and are already part of Swift 3. (I personally 
> wonder how they scale compared to something like libuv, but for now I 
> assume they do ;-)
>
> For making the Unix calls a little nicer Swift extensions on the Unix 
> types are IMO pretty awesome, something along those lines:
>
>   https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift
>
> I would avoid creating wrappers which are then just wrapped again by 
> the higher level frameworks …
>
> The only real thing I’m missing is SSL support. But that already 
> depends quite a lot on how the higher level frameworks deal with 
> streams in general.
>
>> 2. A lil more guidance around timestamps + time zones. These are 
>> super important for decent compliant swift db drivers. Can we rely on 
>> Foundation NSDate and timezones to work well cross platform without 
>> issues here?
>
> If it is part of Foundation you can assume it is supposed to work, 
> right? :-)
>
>> 3. A standard lightweight crypto library to handle authentication. 
>> This is something all database driver authors will have to deal with 
>> (MD5 hashing etc). During the summer I had been switching between a 
>> few libraries but would be great to have this unified, cross platform 
>> support for this. Again I think this falls under the umbrella of this 
>> organization.
>
> +1 (And that should probably be part of Foundation as it is required 
> just the same on the client side).
>
>> 4. Coming from a diverse backend/server background, I’ve seen 
>> different lang+environments handle sql interfaces differently. Most 
>> have left it up to third party frameworks/ecosystems 
>> (ruby/node/python) but some like Golang provide at least a default 
>> SQL interface that driver authors can adapt to. I’m starting to 
>> lean towards the latter of the two but I’m by no means and expert 
>> on anything :). This probably needs more community 
>> engagement/proposal.
>
> IMHO that sounds more like something the higher level frameworks 
> (ORMs) should be concerned about (as they will define what they want 
> to map from and how, and probably in pretty different ways). But maybe 
> not. Personally I’d like to avoid something like JDBC as it provides 
> little value at extra overhead.
>
> As an example: if I have received a DispatchData from the socket 
> containing a PG row values, I don’t want to first convert that to a 
> JDBC or EOAdaptor record-Dictionary<Key,Any>> which is then mapped to 
> a Customer.purchaseStatus enum. I would rather like to pass up that 
> DispatchData to the highest level and only have it converted at the 
> very last point and only if necessary - sometimes an ORM, but other 
> times it may be just directly streamed into a different format, say 
> JSON (in such cases you can often accomplish zero-copy).
>
>> My hope is we can start writing some of the drivers in pure Swift and 
>> help all those frameworks/libs get better too.
>
> Not sure a generic ‘driver' interface will help a lot here. I think 
> you help most by providing a SwiftPQ library which can then be 
> integrated by the ORMs/frameworks in a way which fits best.
>
> Anywayz, interesting to see what people come up with :-)
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev