std.database

[Piotrek via Digitalmars-d]

On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
> If you're trying to connect to a SQL database or a document 
> database, as I'd expect for something called "std.database"

The thing is I strongly encourage to not reserve std.database for 
external database clients and even what is more limiting to SQL 
ones only.

> , it's a pretty terrible API:
>  * No index scans, lookups, or range queries.

Indexes can be supported by strings and CTFE, can't they?
e.g.
filter!q{item.elements.length < 10 && item.model == "Sport"}

>  * No support for complex queries.

Not sure what you mean by complex queries. Also I think the API 
allows arbitrary complex queries.

>  * No support for joins.

Can be done by @attributes or other linking functionality between 
DbCollections.

>  * No support for projections.

You mean something like referring to part of the item's fields?
I see no problem here.

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

Isn't it just the "index support" case?

>  * In your implementation, updates must bring every affected 
> row over the
> wire, then send back the modified row.

In my implementation there is no wire (that's why I call it 
embedded). However I thought we talk about API and not particular 
implementation. I don't see how this API excludes RPC. Query 
strings (e.g. SQL) can be provided in old fashioned way.

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

I think this is just a "must have" for any db engine. I don't see 
how it applies to the proposed API other than any implementation 
of db engine has to handle it properly.

When I say DbCollection should behave similar to an ordinal array 
I don't mean it should be an ordinal array.

>  * The API assumes a total ordering for each DbCollection. This 
> is not valid.

I don't know what you mean here. Example would be good.

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

I'm still not sure if you are referring to my implementation or 
hypothetical API. To be clear: my current implementation is still 
proof of concept and surly *unfinished*. And in case you refer to 
my implementation I plan to support O(1), O(log n) and O(n) 
access patterns with its "rights and duties".

Cheers,
Piotrek