On 13.10.2011 20:30, bls wrote:
Am 13.10.2011 20:16, schrieb simendsjo:
On 13.10.2011 19:49, bls wrote:
Am 13.10.2011 18:44, schrieb simendsjo:
On 13.10.2011 11:53, Steve Teale wrote:
On Thu, 13 Oct 2011 11:22:20 +0200, bls wrote:
> Am 12.10.2011 20:13, schrieb Steve Teale:
>> The way this discussion is going we're going to have four layers,
with
>> the top one written by Jacob.
>
> 1 = etc.c.
> 2 = Database classes
> 3 = ??
> 4 = ORM
>
> Please explain ?
What I meant was that there might be a layer here that would provide a
common interface to the supported databases in terms of literal SQL
commands, as embodied in Andrei's example
I was thinking more like
1) etc.c.mysql/pg - c interface
2) std.sql.mysql/pg - d interface using templates, ranges etc
3) Database classes - common interface
4) ORM
Sorry, I don't get it. IMHO 2) and 3) are at the same level.. F.I.
a draft :
http://pastebin.com/n8H0QF8X
2) doesn't hide any features of the database. If the database supports a
feature, it's here.
3) is a common interface - will hide the specific database, including
features unique for this db.
At any level, you should be able to drop down to the lower levels if
necessary.
Of course... 4) could be built directly on 1), 2) or 3). Step 2) isn't
really needed as long as you can get internal handles and drop down to
1), but having a clean D interface instead would be nice.
Thanks for the feedback.. I am still not there :)
from the snippet..
final class MySQL : IDatabase {
// common _Interface implementation stuff_
public void open(string host,string db,string user,string pw,
const string[string] params) {
}
public void open(string host,string db,string user,string pw) {
}
// _MySQL specific_
public void funkyMySQLstuff() {}
}
what keeps you away to use .. auto db = new MySQL() ?? the MySQL class
can be as close to the metal as you want it to be ?
well, guess we have to wait for the first stuff from Steve. It is just
that I think : design first, implement later.
As long as nothing is missed in the translation, what "layer" exposes
the db specifics is irrelevant. I'm just afraid that higher levels would
have stuff like "void funkyMySQLstuff()", while the actual
implementation would be "ComplexStruct
funkyMySQLstuff(ParamFromOtherFunkyMethod a, SeveralOtherOptions b)" and
be missing important options and possible optimizations.
