I’m actively working on the low level interface and I’m making good progress.  My goal is to have a high quality interface definition with working reference drivers for top tier databases.  The current references drivers are ODBC, sqlite, mysql, and Oracle.

I think it’s important to support ODBC since it covers all bases, but I agree that ODBC alone is not sufficient.  The main reason is that most application developers coming from other stacks will be expecting direct drivers and are not likely to be happy dealing with the added complications of ODBC.   However, I think both are achievable in the near term under a common interface.

On the async question, the native interfaces are traditionally synchronous and that’s my initial focus.   I will need to look at which native interfaces actually support it and see how that can be mapped into the generic interface, but synchronous needs to be supported.

There is a known issue with RefCounted that needs to be addressed.  There is a apparently a race condition with the reference counter when RefCounted is within a class.  Nearly all of the types in my design are ref counted structs and there are use cases for embedding those objects in classes.  There was discussion at the conference on this and I believe the preferred solution is for the GC have some thread affinity on collection.

On Thursday, 11 June 2015 at 12:47:46 UTC, Steven Schveighoffer wrote:
> On 6/9/15 6:05 PM, Jonathan M Davis wrote:
>> On Tuesday, 9 June 2015 at 18:49:04 UTC, Brad Anderson wrote:
>>> We also have map in the form of RedBlackTree. I think you might be
>>> able to use RedBlackTree for a set too but I haven't tried it.
>>
>> You can, but it's a bit of a pain, because you have to keep passing it a
>> tuple where the value gets ignored. We really need a wrapper around it
>> to make it cleaner.
>
> Map is a pain. Set is not. The apparatus around RedBlackTree in dcollections to turn it into a map is non-trivial, and is worthy of having in std.container. TreeSet, however, was pretty much straight mapping to implementation calls.

You're right. It's been too long since I used it, and I didn't think it through enough. As I recall, the main problem has to do with all of the cases that you have to pass in a tuple where only the key matters, and for some reason, I was thinking that that was the set case, when it's obviously the map case. The set case could pretty much be an alias if we wanted TreeSet or SortedSet in the library, whereas TreeMap/SortedMap would need to be a wrapper around RedBlackTree.

- Jonathan M Davis