Alexey,

On Tue, 2010-11-16 at 01:14 +0000, Alexey Khmara wrote:
> Hello!
> 
> I tried to find any module to work with SQLite3 in D2, and failed. I
> found either just bindings to old SQLite versions or D1 modules with
> "craft-SQL-on-the-fly" interface, all abandoned.
> So I want to add just another D2 SQLite3 bindings and OO-wrapper and
> uploaded to GitHub: https://github.com/bayun/SQLite3-D

I cloned the repository which gets the sqlite.d file but there seems to be no unit tests, system tests or examples?

Also should the API be retargetable to any SQL resource rather than just being targeted at SQLite?

> It seems that no-one wants to support bindings for current SQLite
> version.. Well, I'll try to do this. But I currently use very small
> subset of it's features, so it's mostly mechanical translation without
> further testing.
> My tiny OO interface supports prepare/bind style of statements, and
> seems to work good :-) But I'm new to D, and will be grateful to
> somebody who can check, if my code is correct and don't have subtle
> bugs.

Can you put some examples of how to use your package?  Reading the source tells me a lot, but not how you intend things to be used.

[ . . . ]

You may want to look at the way Groovy handles this sort of stuff.  Most languages bind at a very low level so that people end up simply embedding SQL statements in strings, or if you are lucky template strings.  Groovy adds a layer above this using the meta-object protocol features to create a very nice builder approach to interacting with the database.  Basically you code up everything in Groovy code and the infrastructure handles composing the SQL and all the connections and cursors.

I am about to look at Python's SQLAlchemy, Python also has other stuff for trying to raise the level.

In terms of support in D, there needs to be a low level drivers I am sure, but having a way of interacting with SQLite, DB2, Oracle, even SQL Server all from the same source code would be good.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Thanks for the reply, Russel!

Ok, I'll add unit tests and some example.

As for support for other databases, it's complex enough task to design good
common database layer, while I currently need only SQLite. Apart from
that, there are
very few types in SQLite, and these tipes map into D's intenal types
very well. To support
other databases I need to do something with all those DateTime,
Timestamp, Decimal...
Usually I don't use them, so do not have any experience with them and
fardly can correctly
design work with them/
I still can build basic common logic and add support to MySQL (at
least I know it and
use sometimes), but I'm pretty new to D and want to receive better
feel of a language before
trying to design some generic database-access library. Also, generic
APIs tend to be more
verbose than I like, and I never seen in practise easy switch from one
database to another -
eiher you need to rewrite all your SQL or you use ORM and lose 3/4 of speed...

I don't know Groovy, but in examples I found something interesting.
Besides variable expansion
(I don't understend how to implement it in D) I see something that can be done.

Using standart interface for iterating dataset - it can be interesting
to allow algorithms run on
datasets, and I can implement forward iterator easily. But access to
values (types of values
are unknown in compile-time) will be tricky. My be, I'll convert all
values into strings for this type of
interface.

Support for name-based arguments. I like it, but I'm thinking on interface now.
There is some ideas:
- use associative array approach like st.bind(["id":1, "name":"Alex
Khmara"] - but this will limit
argument types to be string,  and I will need to conver them
automatically when doing biding.
- another aproach would be do someting like
st.bind("id",1).("name"."Alex Khmara"), but it's ugly for me.
- may be preferred way - use tuples, like (st.bindNamed(["id": 1]
["name": "Alex Khmara"]).

With first case we are able to fill array with some cycles, and with
other two variants
we cannot, but first case limits us to common type for all arguments -
i.e. string. So I'm thinking
on this.

May be I need to start use library-based tuples for all this machinery...

I definitely do not plan to add anything with automatic SQL generation -
I don't seen any that is easy and fast, but may be it would be good to support
some compile-time generation of datasets with felds of known type.
D wold be good in this field. I'll will think on it.

2010/11/16 Russel Winder <russel@russel.org.uk>:
> Alexey,
>
> On Tue, 2010-11-16 at 01:14 +0000, Alexey Khmara wrote:
>> Hello!
>>
>> I tried to find any module to work with SQLite3 in D2, and failed. I
>> found either just bindings to old SQLite versions or D1 modules with
>> "craft-SQL-on-the-fly" interface, all abandoned.
>> So I want to add just another D2 SQLite3 bindings and OO-wrapper and
>> uploaded to GitHub: https://github.com/bayun/SQLite3-D
>
> I cloned the repository which gets the sqlite.d file but there seems to be no unit tests, system tests or examples?
>
> Also should the API be retargetable to any SQL resource rather than just being targeted at SQLite?
>
>> It seems that no-one wants to support bindings for current SQLite
>> version.. Well, I'll try to do this. But I currently use very small
>> subset of it's features, so it's mostly mechanical translation without
>> further testing.
>> My tiny OO interface supports prepare/bind style of statements, and
>> seems to work good :-) But I'm new to D, and will be grateful to
>> somebody who can check, if my code is correct and don't have subtle
>> bugs.
>
> Can you put some examples of how to use your package?  Reading the source tells me a lot, but not how you intend things to be used.
>
> [ . . . ]
>
> You may want to look at the way Groovy handles this sort of stuff.  Most languages bind at a very low level so that people end up simply embedding SQL statements in strings, or if you are lucky template strings.  Groovy adds a layer above this using the meta-object protocol features to create a very nice builder approach to interacting with the database.  Basically you code up everything in Groovy code and the infrastructure handles composing the SQL and all the connections and cursors.
>
> I am about to look at Python's SQLAlchemy, Python also has other stuff for trying to raise the level.
>
> In terms of support in D, there needs to be a low level drivers I am sure, but having a way of interacting with SQLite, DB2, Oracle, even SQL Server all from the same source code would be good.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>



-- 
С уважением,
Алексей Хмара

[ ... ]
>
> In terms of support in D, there needs to be a low level drivers I am
> sure, but having a way of interacting with SQLite, DB2, Oracle, even SQL
> Server all from the same source code would be good.
>

On one hand, I agree with this. It's nice to be able to easily switch the DB backend without modifying the code.
On the other hand, sqlite is a very small, lighweight, external-server-less DB backend, which makes it useful for projects where other systems aren't. Sometimes I want to use sqlite in a small project, and I don't need nor want the extra complexity. I just want sqlite. This actually led me to use directly the C library instead of DDBI in a D1 small project of mine a couple of years ago. Just one .d file dropped into my project dir.

So maybe, it's possible to make the DB framework use plugins, and only install the one we want; or maybe two different projects with same syntax (more convenient for the user but bound to fail in the longer term).

>From user side it's not hard to make it simple. Differences could be minimized,
plugins added etc. I'll try to add MySQL, and if it's possible to implement common interface, I'll do it. But I'm not sure that it will be easy.

2010/11/16 Diego Cano Lagneaux <d.cano.lagneaux@gmail.com>:
> [ ... ]
>>
>> In terms of support in D, there needs to be a low level drivers I am sure, but having a way of interacting with SQLite, DB2, Oracle, even SQL Server all from the same source code would be good.
>>
>
> On one hand, I agree with this. It's nice to be able to easily switch the DB
> backend without modifying the code.
> On the other hand, sqlite is a very small, lighweight, external-server-less
> DB backend, which makes it useful for projects where other systems aren't.
> Sometimes I want to use sqlite in a small project, and I don't need nor want
> the extra complexity. I just want sqlite. This actually led me to use
> directly the C library instead of DDBI in a D1 small project of mine a
> couple of years ago. Just one .d file dropped into my project dir.
>
> So maybe, it's possible to make the DB framework use plugins, and only install the one we want; or maybe two different projects with same syntax (more convenient for the user but bound to fail in the longer term).
>



-- 
С уважением,
Алексей Хмара

Alexey Khmara Wrote:

> There is some ideas:
> - use associative array approach like st.bind(["id":1, "name":"Alex
> Khmara"] - but this will limit
> argument types to be string,  and I will need to conver them
> automatically when doing biding.

There's Variant, though I don't know, whether AA will work with it, there were some AA bugs.

Why use dynamic Variant if there is static tuples? As for me, syntax bind(["id":1], ["name":"myName"]) is better.

2010/11/16 Kagamin <spam@here.lot>:
> Alexey Khmara Wrote:
>
>> There is some ideas:
>> - use associative array approach like st.bind(["id":1, "name":"Alex
>> Khmara"] - but this will limit
>> argument types to be string,  and I will need to conver them
>> automatically when doing biding.
>
> There's Variant, though I don't know, whether AA will work with it, there were some AA bugs.
>



-- 
С уважением,
Алексей Хмара

Alexey Khmara Wrote:

> Why use dynamic Variant if there is static tuples? As for me, syntax bind(["id":1], ["name":"myName"]) is better.

That's not tuples, that's AAs, and they're quite dynamic.

Yes. I need to sleep more... Anyway syntax is better - it's compact
enough and it shows
pairs "key-value".

2010/11/16 Kagamin <spam@here.lot>:
> Alexey Khmara Wrote:
>
>> Why use dynamic Variant if there is static tuples? As for me, syntax bind(["id":1], ["name":"myName"]) is better.
>
> That's not tuples, that's AAs, and they're quite dynamic.
>



-- 
WBR,
Alexey Khmara