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).
