I have some additions to my lib projects
(to release very soon):
- updated libpq postgreSQL wrapper (dpq)
- sqlite3 wrapper
- common interface for dpq and sliqte (DDBC)
- cliente for DDBC
- dool (d object oriente runtime lib)
- DUI now depends on dool

what's the importance of keeping these things independent?

I believe my projects are mostly ignored by the community so
I'm thinking of integrating every thing into dool and DUI
keeping just those two libs.
I would do that for ease of maintenance and distribution.
These libs would be compiled including or not external
dependencies (sqlite3, postgreSQL and others on the future)
I'll keep dool separated from DUI because, because...(?)

if you don't care just don't reply.
if no strong arguments against integration are presented in
a couple of days I'll just go ahead (this time just bundle
the SQL things into dool and the client into duiextra or
something like that)

http://dool.sourceforge.net
http://dpq.sourceforge.net
http://dui.sourceforge.net
http://leds.sourceforge.net

Ant

If its easier to maintain as one or two libraries, I say "go for it".  The worst that can happen is if someone has a requirement that you break things back out (unlikely).

FYI, I am shopping around for future DB components to use in DSP once it matures to that point. ;)

In article <cj95rs$s51$1@digitaldaemon.com>, Ant says...
>
>I have some additions to my lib projects
>(to release very soon):
>- updated libpq postgreSQL wrapper (dpq)
>- sqlite3 wrapper
>- common interface for dpq and sliqte (DDBC)
>- cliente for DDBC
>- dool (d object oriente runtime lib)
>- DUI now depends on dool
>
>what's the importance of keeping these things independent?
>
>I believe my projects are mostly ignored by the community so
>I'm thinking of integrating every thing into dool and DUI
>keeping just those two libs.
>I would do that for ease of maintenance and distribution.
>These libs would be compiled including or not external
>dependencies (sqlite3, postgreSQL and others on the future)
>I'll keep dool separated from DUI because, because...(?)
>
>if you don't care just don't reply.
>if no strong arguments against integration are presented in
>a couple of days I'll just go ahead (this time just bundle
>the SQL things into dool and the client into duiextra or
>something like that)
>
>http://dool.sourceforge.net
>http://dpq.sourceforge.net
>http://dui.sourceforge.net
>http://leds.sourceforge.net
>
>Ant
>
>

version(DNG) pragma(EricAnderton,"yahoo");

In article <cj9738$t01$1@digitaldaemon.com>, pragma says...
>
>If its easier to maintain as one or two libraries, I say "go for it".  The worst that can happen is if someone has a requirement that you break things back out (unlikely).
>
>FYI, I am shopping around for future DB components to use in DSP once it matures to that point. ;)

DDBC defines the Connection, Statement, ResultSet model found on
other database drivers.
also supplies Tuple and Meta Tuple information (I kinda of like it).

dpq still contains the the d wrappers to the specific libpc API.

>
>In article <cj95rs$s51$1@digitaldaemon.com>, Ant says...
>>
>>I have some additions to my lib projects
>>(to release very soon):
>>- updated libpq postgreSQL wrapper (dpq)
>>- sqlite3 wrapper
>>- common interface for dpq and sliqte (DDBC)
>>- cliente for DDBC
>>- dool (d object oriente runtime lib)
>>- DUI now depends on dool
>>
>>what's the importance of keeping these things independent?
>>
>>I believe my projects are mostly ignored by the community so
>>I'm thinking of integrating every thing into dool and DUI
>>keeping just those two libs.
>>I would do that for ease of maintenance and distribution.
>>These libs would be compiled including or not external
>>dependencies (sqlite3, postgreSQL and others on the future)
>>I'll keep dool separated from DUI because, because...(?)
>>
>>if you don't care just don't reply.
>>if no strong arguments against integration are presented in
>>a couple of days I'll just go ahead (this time just bundle
>>the SQL things into dool and the client into duiextra or
>>something like that)
>>
>>http://dool.sourceforge.net
>>http://dpq.sourceforge.net
>>http://dui.sourceforge.net
>>http://leds.sourceforge.net
>>
>>Ant
>>
>>
>
>version(DNG) pragma(EricAnderton,"yahoo");

Ant wrote:
> I have some additions to my lib projects
> (to release very soon):
> - updated libpq postgreSQL wrapper (dpq)
> - sqlite3 wrapper - common interface for dpq and sliqte (DDBC)
> - cliente for DDBC
> - dool (d object oriente runtime lib)
> - DUI now depends on dool
> 
> what's the importance of keeping these things independent?
> 
> I believe my projects are mostly ignored by the community so
> I'm thinking of integrating every thing into dool and DUI
> keeping just those two libs.
> I would do that for ease of maintenance and distribution.
> These libs would be compiled including or not external
> dependencies (sqlite3, postgreSQL and others on the future)
> I'll keep dool separated from DUI because, because...(?)
> 
> if you don't care just don't reply.
> if no strong arguments against integration are presented in
> a couple of days I'll just go ahead (this time just bundle the SQL things into dool and the client into duiextra or
> something like that)
> 
> http://dool.sourceforge.net
> http://dpq.sourceforge.net
> http://dui.sourceforge.net
> http://leds.sourceforge.net
> 
> Ant
> 
> 
I don't know dool...(no files release on sourceforge, sketchy description, makes it difficult to evaluate).  OTOH, I'm quite interested in the sqlite3 wrapper.  Only problem is that sqlite2 is what I have installed, and it'll probably stay that way until after I upgrade to the 2.6 kernel.  Then I'll see what I need to upgrade to install sqlite3.  (It doesn't seem to be a part of the Debian packages.)

Currently I'm building a package in Ruby using Sqlite, but I have the intention of moving it to D when it's more complete.

In article <cj9rg9$19mm$1@digitaldaemon.com>, Charles Hixson says...
>
>Ant wrote:
>> I have some additions to my lib projects
>> 
>> 
>I don't know dool...(no files release on sourceforge, sketchy description, makes it difficult to evaluate).

I forgot that, see the manifest at: http://sourceforge.net/forum/forum.php?thread_id=1121037&forum_id=394961

>  OTOH, I'm quite
>interested in the sqlite3 wrapper.

If you want a thin wrapper try Vathix's.
The thing is very simple.
Mine completly hides the sqlite3 C API.

> Only problem is that sqlite2 is
>what I have installed, and it'll probably stay that way until after I upgrade to the 2.6 kernel.

You should check first,
but I'm prety sure you can have both versions installed.

>  Then I'll see what I need to upgrade
>to install sqlite3.  (It doesn't seem to be a part of the Debian packages.)
>
>Currently I'm building a package in Ruby using Sqlite, but I have the intention of moving it to D when it's more complete.

ah! double the work ;)

Ant

> You should check first,
> but I'm prety sure you can have both versions installed.

According to the documentation you can but you have to watch for the linkage between the version numbers... or something. Read docs, they have more and better information... I don't think I'm talking to Ant but the Other Guy(tm).

Jacob Santos

Gold Dragon wrote:
>> You should check first,
>> but I'm prety sure you can have both versions installed.
> 
> 
> According to the documentation you can but you have to watch for the linkage between the version numbers... or something. Read docs, they have more and better information... I don't think I'm talking to Ant but the Other Guy(tm).
> 
> Jacob Santos

Thanks, but I want my attention focused elsewhere.  And by the time I start worrying about efficiency we'll probably be as Sqlite4. (OTOH, if the thing by Vathix looks good, perhaps I'll start switching immediately.)

Charles Hixson wrote:
> ...hanks, but I want my attention focused elsewhere.  And by the time I start worrying about efficiency we'll probably be as Sqlite4. (OTOH, if the thing by Vathix looks good, perhaps I'll start switching immediately.)

Mmph.  It turns out that was the Sqlite3 binding I was thinking of.  So I'll wait-a-bit.