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
