Right after allocators: containers or database connectivity?

Nick Sabalausky via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 11 10:59:22 PDT 2015


On 06/09/2015 01:53 PM, Jacob Carlborg wrote:
>
> I vote for databases. I also vote for an interface that is independent
> of ODBC, but ODBC could be one of the drivers that implements this
> interface. I know that there's a native implementation of the MySQL
> protocol on code.dlang.org.
>

This is kind of my thought, too.

I haven't felt constrained by the lack of containers beyond what's 
built-in. And if I do, I can look into dcollections. It's arguably an 
optimization issue anyway. YES, Granted, algorithmic optimization is THE 
BIGGEST optimization by far, but aside from maybe "big data" domains it 
doesn't actually enable you to do things you just plain couldn't do at 
all otherwise.

Databases, OTOH, are something where you either can do it, or you just 
plain CAN'T. And with D it's currently a bit more on the "can't" side, 
especially if you don't want your app tied to just one DBMS. And unlike 
containers, the state of D databases actually HAS been an issue for me.

That said, tossing an ODBC wrapper in phobos doesn't really solve the DB 
issue. It would certainly be GOOD to have a good ODBC lib for D, no 
doubt, but:

1. There is apparently question as to whether it belongs in Phobos.

2. There's also question about async I/O. A *LOT* of DB users are also 
going to be Vibe.d users, so we cannot afford to have problems in this 
area. Perhaps what we need to look at is getting Vibe's async I/O (or at 
least some low-level portion of it, if that even makes sense?) into 
Phobos somehow?

3. As useful as ODBC may be, it still doesn't eliminate the need for 
direct drivers.

4. What's REALLY needed regarding DBs is a good, well-designed low-level 
interface capable of handling both ODBC and individual drivers. ORMs 
should be something separate, built on top of this later. This low-level 
part might either include NoSQL (if reasonable to do so) or leave NoSQL 
up to a separate interface (if need be).



More information about the Digitalmars-d mailing list