> 1. In my opinion it should not be called std.database, but let's say "std.dbc".
> This is because it looks like a wrapper over db clients.  Moreover one may say it's almost impossible to make a common and effective interface which would work with all databases. e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC today")

I agree that std.dbc would be more accurate, although I like std.database better because it is more recognizable.  Another option could be std.database.client.

ODBC is less important now as there are fewer desktop applications that connect directly to databases.  There is at least one example related to D, which is the ODBC driver for presto, which is used in Excel.  Server side code is generally written using the underlying native client directly.  However ODBC support is useful in that it represents a catch all that covers all databases for which a native client is not yet supported.

At least for the SQL databases, a standard interface is definitely achievable and I believe that it having it would allow D to get more traction as an application platform.

> 2. I'm not against such a functionality in Phobos. However your project seems to be a duplication of the DDBC project. And it was not proposed for inclusion so often.

There are a number of areas where this design is an improvement over DDBC: ease-of-use, better resource management (no scope, no GC), phobos compatibility, to name a few.  There is a lot more that needs to be added to make it standards grade.


> 3. What I call a D Database API could be described as:
>  - Database object
>  - DbCollection object (equivalent to array)
>  - ranges + std.algorithm

My design is indeed range based:  stmt.range() returns a forward range proxy for the query results (the accessor name might change however).

Your engine project is interesting.  I think there is common ground in the interfaces in the two projects, particularly in how the interface for the results might work. I will look more closely at the details to see what might be workable.

erik

On Wednesday, 2 March 2016 at 15:41:56 UTC, Piotrek wrote:
> On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
>>[...]
>
> My quick comments:
>
> 1. In my opinion it should not be called std.database, but let's say "std.dbc".
> This is because it looks like a wrapper over db clients.  Moreover one may say it's almost impossible to make a common and effective interface which would work with all databases. e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC today")
>
> [...]

Looks good.
At least at a first glace it seems pretty similar to SQLite.
I'd like to take this api for sqlite-d.

Because it seems to fit quite naturally.

On Wednesday, 2 March 2016 at 03:07:54 UTC, Rikki Cattermole wrote:
> Okay I've found a problem.
>
> Here is some code demonstrating it.
> http://dpaste.dzfl.pl/022c9e610a18
>
> Now take a look again at Database https://github.com/cruisercoder/dstddb/blob/master/src/std/database/poly/database.d#L37
>
> Do you see the problem?
> The solution is simple.
>
> The client database type can be a struct or a class. It doesn't matter too much (assuming you're going the way of ranges).
> But the intermediary representation must be on the heap and should probably use the constructor and not a static create method to get it.
> This way people can use other memory management solutions and construct it however they like.

How is this a UAF? Isn't the struct copied?

On Wednesday, 2 March 2016 at 18:28:34 UTC, landaire wrote:
> How is this a UAF? Isn't the struct copied?

Ah I think I misunderstood. You mean in the database, not the dpaste?

On Wednesday, 2 March 2016 at 15:41:56 UTC, Piotrek wrote:
> Moreover one may say it's almost impossible to make a common and effective interface which would work with all databases. e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC today")

I believe that section is about PHP forums being locked to mysql, and performance is not the reason for that. Mostly because mysql support is builtin, works for most things and is provided by hosters.

On Wed, 02 Mar 2016 15:41:56 +0000, Piotrek wrote:
> 3. What I call a D Database API could be described as:
>   - Database object
>   - DbCollection object (equivalent to array)
>   - ranges + std.algorithm

It looks like you're trying to write a LevelDB analogue that implements an array rather than a key/value collection -- and that's a decent start.

If you're trying to connect to a SQL database or a document database, as
I'd expect for something called "std.database", it's a pretty terrible
API:
 * No index scans, lookups, or range queries.
 * No support for complex queries.
 * No support for joins.
 * No support for projections.
 * No support for transactions.
 * If you add support for transactions, you'll crash all the time because
the transactions got too large, thanks to the full table scan mentality.
 * In your implementation, updates must bring every affected row over the
wire, then send back the modified row.
 * Updates affect an entire row. If one process updates one field in a
row and another one updates a different field, one of those writes gets
clobbered.
 * The API assumes a total ordering for each DbCollection. This is not
valid.
 * If there are multiple rows that compare as equals, there's no way to
update only one of them in your implementation.
 * In your implementation, updating one row is a ϴ(N) operation. It still
costs ϴ(N) when the row you want to update is the first one in the
collection.

On 03/03/16 8:36 AM, landaire wrote:
> On Wednesday, 2 March 2016 at 18:28:34 UTC, landaire wrote:
>> How is this a UAF? Isn't the struct copied?
>
> Ah I think I misunderstood. You mean in the database, not the dpaste?

Correct. My code was just to showcase the problem.

On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
> I'm back to actively working on a std.database specification & implementation.  It's still unstable, minimally tested, and there is plenty of work to do, but I wanted to share an update on my progress.

I suggest you call the package stdx.db - it is not (and may not become) a standard package, so `std` is out of question. If it is supposed to be *proposed* as standard package, then `stdx` is good because that is what some people have used in the past (while others used the ugly std.experimental. for the same purpose).

I humbly believe that this effort **must** be collaborative as such package is doomed to fail if done wrong.

> I suggest you call the package stdx.db - it is not (and may not become) a standard package, so `std` is out of question. If it is supposed to be *proposed* as standard package, then `stdx` is good because that is what some people have used in the past (while others used the ugly std.experimental. for the same purpose).
>
> I humbly believe that this effort **must** be collaborative as such package is doomed to fail if done wrong.

I totally agree that it must be collaborative and community driven.  I failed to add the proposed qualifier in this thread - sorry about that.   Right now I'm just trying to put together enough of a substantive design to be worthy of  discussion.   While I'm presenting a design the way I think it should work, I'm definitely asking for feedback and especially opposition to any aspect of it.   My package name choice is just an example, the package name would have to be changed to whatever the "D committee" thinks is appropriate.

erik

Also member names: methods are named after verbs, you use nouns. Method `next` is ambiguous: is the first row the next row? `fetch` or `fetchRow` would be better.