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 <[email protected]>:
> 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:[email protected]
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
--
С уважением,
Алексей Хмара
