[std.database]

Jacob Carlborg doob at me.com
Tue Oct 11 01:07:26 PDT 2011


On 2011-10-11 05:08, Johann MacDonagh wrote:
> On 10/8/2011 2:43 AM, Steve Teale wrote:
>> I use this title at Andrei's suggestion, and repeat his idea that it
>> be used
>> as a prefix for discussions as we navigate toward a design. Unless
>> there is
>> resistance to the idea, I will on the job of implementing whatever we
>> decide
>> is appropriate. I am retired, and have the time to do it.
>>
>> It seems that every man, and possibly his dog, has a private
>> implementation
>> for at least a favorite DB, so we should have plenty of material to
>> build on.
>>
>> At this point I would like to get responses from those who feel they are
>> likely to contribute to the design through to completion.
>>
>> I'd also like to get a feel for the magnitude of the task, so I'd like
>> to ask
>> what database systems you think should be supported.
>>
>> I have started a github account, and will put my mysqld stuff there
>> shortly,
>> then you can kick me out if you don't like what you see.
>>
>> Steve
>
> I've written up a prototype for a "LINQ" style database querying
> mechanism in D (read about "LINQ to SQL" if you've never heard of it).
> Legally speaking, it has very little to do with LINQ, but the concept is
> similar.
>
> Basically, it allows you to write code like this:
>
> auto x = new SqliteConnection("mydata.db");
>
> foreach(y; x.MyTable.where("someField > 10"))
> {
> // y is a wrapper around Variant[string] with some opDispatch magic
> writeln(to!string(y.MyField));
> writeln(to!int(y.SomeOtherField));
> }
>
> Of course, "MyTable" is handled via opDispatch. The SqliteConnection
> doesn't care what tables are available in "mydata.db". You can also do
> much more. Such as:
>
> x.MyTable.startAt(20).limit(10).where("blah").select("somefield",
> "sometingElse");
>
> In addition, you should be able to do something like this (don't think
> I've implemented this yet):
>
> x.MyTable.select!MyStruct();
>
> Doing that would return a range of MyStruct structs, rather than the
> wrapper around Variant[string] like above. This would allow you to do:
>
> auto x = new SqliteConnection("mydata.db");
>
> foreach(y; x.MyTable.where("someField > 10").select!MyStruct())
> {
> // y is a wrapper around Variant[string] with some opDispatch magic
> writeln(y.MyField); // No more needing the to! template
> writeln(y.SomeOtherField);
> }
>
> Of course, this would allow you to find typos in field names at compile
> time (provided your struct is kept in sync with the database), and means
> you don't have to go through the Variant[string] for all your database
> accesses.
>
> To implement this, a database "driver" would have to have a shared
> opDispatch implementation (perhaps done with a mixin or maybe with an
> abstract class), and it would have to be able to translate the "query"
> into a SQL query that works with their underlying database system.
>
> I have a working prototype somewhere that works with Sqlite, and it
> seems to work very nicely. Clearly a system like this shows off what D
> can do out of the box (opDispatch), and makes writing scripts very easy.
>
> Let me know if this is something you think should be part of
> std.database (or whatever we end up calling it).

I think that the use of opDispatch and selecting with a struct should be 
available at the higher level interfaces and not in the low level interface.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list