haskelldb-users — For questions, suggestions, bug reports and patches

Re: [Haskelldb-users] broken BOOLEANs

[Matthias R. <mat...@so...>]

Matthias Radestock <mat...@so...> writes:

>   fromSql: cannot convert SqlString "t" to Bool
>
> Is this a bug in HDBC or haskelldb?

Having looked into this a bit more, I am pretty sure it's a bug in
HDBC. I'll let the maintainers know.


Matthias.

[Haskelldb-users] broken BOOLEANs

[Matthias R. <mat...@so...>]

When I generate db bindings with DBDirect using the HSQL.PostgreSQL
driver, columns of type BOOLEAN get represented by the haskell type
'String'. That's wrong, but at least it works. By contrast, when using
the HDBC.PostgreSQL driver BOOLEANs get represented by 'Bool', which is
correct, but when I run queries I get the error

  fromSql: cannot convert SqlString "t" to Bool

Is this a bug in HDBC or haskelldb?


Matthias.

Re: [Haskelldb-users] DBDirect with HDBC

[Bjorn B. <bri...@cs...>]

On Jul 20, 2006, at 3:16 PM, Matthias Radestock wrote:

> It appears to be impossible to run DBDirect with the HDBC drivers. It
> calls dynConnect_, which only supports HSQL. Is that intentional or is
> the lack of HSQL support in dynConnect_ and DBDirect simply an =20
> omission?

It's an omission. Patches are welcome.

/Bj=F6rn=

[Haskelldb-users] DBDirect with HDBC

[Matthias R. <mat...@so...>]

It appears to be impossible to run DBDirect with the HDBC drivers. It
calls dynConnect_, which only supports HSQL. Is that intentional or is
the lack of HSQL support in dynConnect_ and DBDirect simply an omission?

Matthias

Re: [Haskelldb-users] ghc chokes on driver-dynamic

[Matthias R. <mat...@so...>]

Bjorn Bringert <bri...@cs...> writes:

> There are sometimes problems like this one when you have old versions
> compiled or installed.

I congratulate the ghc developers for their particularly fine choice of
error message produced in this case.

> Try this:
>
> - First unregister all haskelldb packages:
>
> $ ./unregister-all
>
> - The make clean before configuring and building each package:
>
> (For haskelldb and each driver-X:)
>
> $ runghc Setup.hs clean
> $ runghc Setup.hs configure
> $ runghc Setup.hs build
> $ runghc Setup.hs install

That fixed it. Thanks.


Matthias.

Re: [Haskelldb-users] ghc chokes on driver-dynamic

[Bjorn B. <bri...@cs...>]

On Jul 19, 2006, at 11:28 AM, Matthias Radestock wrote:

> I grabbed the latest haskelldb version from darcs and tried to install
> it. haskelldb itself built and installed fine, but when I try to build
> the driver-dynamic module I get:
>
> <snip>
> cd /usr/local/src/haskelldb/driver-dynamic/
> runghc Setup.hs build
> Preprocessing library haskelldb-dynamic-0.10...
> Preprocessing executables for haskelldb-dynamic-0.10...
> Building haskelldb-dynamic-0.10...
> ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC =20
> version 6.4.1):
> 	unknown exception
>
> Please report it as a compiler bug to glasgow-haskell-=20
> bu...@ha...,
> or http://sourceforge.net/projects/ghc/.
> </snip>
>
> Is anybody else seeing this? It may be a 6.4.1 bug, but a) this worked
> fine until recently, b) I'd rather not have to upgrade ghc.

There are sometimes problems like this one when you have old versions =20=

compiled or installed. Try this:

- First unregister all haskelldb packages:

$ ./unregister-all

- The make clean before configuring and building each package:

(For haskelldb and each driver-X:)

$ runghc Setup.hs clean
$ runghc Setup.hs configure
$ runghc Setup.hs build
$ runghc Setup.hs install

/Bj=F6rn=

[Haskelldb-users] ghc chokes on driver-dynamic

[Matthias R. <mat...@so...>]

I grabbed the latest haskelldb version from darcs and tried to install
it. haskelldb itself built and installed fine, but when I try to build
the driver-dynamic module I get:

<snip>
cd /usr/local/src/haskelldb/driver-dynamic/
runghc Setup.hs build
Preprocessing library haskelldb-dynamic-0.10...
Preprocessing executables for haskelldb-dynamic-0.10...
Building haskelldb-dynamic-0.10...
ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1):
	unknown exception

Please report it as a compiler bug to gla...@ha...,
or http://sourceforge.net/projects/ghc/.
</snip>

Is anybody else seeing this? It may be a 6.4.1 bug, but a) this worked
fine until recently, b) I'd rather not have to upgrade ghc.


Matthias.

Re: [Haskelldb-users] Release

[Bjorn B. <bri...@cs...>]

On Jul 17, 2006, at 1:37 PM, Bjorn Bringert wrote:

> On Jul 17, 2006, at 1:14 PM, Matthias Radestock wrote:
>
>> Bjorn Bringert <bri...@cs...> writes:
>>
>>> I think that some sort of test suite would be very nice to have
>>> before a release, but that might just be my personal opinion.
>>
>> IMHO the test suite is *essential*. HaskellDB is quite a complex
>> library
>> and changes in one area can have far-reaching and non-obvious
>> consequences. In absence of a large user base, a reasonably
>> comprehensive test suite is crucial for tracking down bugs. I was
>> horrified when I found out that the current test suite had
>> bit-rotted. It means that all recent changes are highly suspect and
>> will
>> have most likely broken something somewhere.
>>
>> Bjorn, do you know when the test suite was last run successfully? =20
>> Then
>> we could take a look what changes were introduced since then and add
>> test cases for those. Ideally we'd also do coverage testing to
>> determine
>> what other tests we should add to get a reasonably good coverage of
>> the
>> library.
>>
>> One added complication is that the test suite should be run against a
>> variety of db backends, in order to identify db-specific code that =20=

>> has
>> crept into the generic code base, and bugs in the db-specific code
>> itself.
>
> I don't think that it would be too hard to get the current tests
> running again, but they were never that good:
>
> - There has never been a time when all of them worked on all back-
> ends, because of back-end incompatibilities.
> - The coverage is probably quite poor.
> - Many of them don't check their outputs, they mostly just test that
> HaskellDB doesn't generate bad SQL or crash in some other way.
>
> Some ideas for getting a good test suite together:
>
> - Design a test database and write DBInfo for it.
>
> - Use DynConnect for database connections. Extend DynConnect to
> support all driver (missing HDBC drivers at the moment)
>
> - Have some way for the user to provide connection parameters to all
> the database back-ends to test with.
>
> - Use HUnit, and maybe even QuickCheck.
>
> - Maybe the FlatDB [1] backend could be used as a reference. It's a
> simple database back-end whose query language is HaskellDB's internal
> PrimQuery type.
>
>
> One of the reasons that this hasn't been done yet is that the back-
> end incompatibility problem is so frustrating. But a test suite would
> be a good way to identify the things that need to be taken care of by
> any back-end specific SQL generation.
>
> I can try to get a test framework together. Are there any volunteers
> who would like to contribute test DB layout, data, unit tests or
> QuickCheck properties?
>
> /Bj=F6rn
>
> [1] http://www.cs.chalmers.se/~bringert/darcs/haskelldb-flat/

I've cleaned up the repo a bit, and added a unit test framework and =20
some unit tests. I have bumped the version number to 0.10, to =20
distinguish it from the released 0.9.

To run the current tests:

$ cd make

Edit test.config and set parameters for whatever database back-ends =20
you have available.

$ make

If you want to run tests for just one of the back-ends in test.config =20=

(for example "HSQL PostgreSQL"):

$ make tests

$ ./tests "HSQL PostgreSQL"

The current tests are very simple, but a large number of them fail on =20=

the some of the back-ends. There even seems to be one in the HDBC =20
back-end which crashes the test framework occasionally.

You are all welcome to contribute more unit tests. Very little of the =20=

API is currently covered. There should also be test for known bugs, =20
see http://sourceforge.net/tracker/?group_id=3D101095&atid=3D629040

I haven't gotten around to adding support for QuickCheck properties yet.


/Bj=F6rn=

Re: [Haskelldb-users] Release

[Shae M. E. <sh...@Sc...>]

Bjorn Bringert <bri...@cs...> writes:

> - Maybe the FlatDB [1] backend could be used as a reference. It's a simple
> database back-end whose query language is HaskellDB's internal PrimQuery
> type.

> I can try to get a test framework together. Are there any volunteers who
> would like to contribute test DB layout, data, unit tests or QuickCheck
> properties?

I'd happily contribute QuickCheck properties. I'm in favor of a FlatDB backend
for the reference implementation, it'll be easy to test.
-- 
I've tried to teach people autodidactism,                | ScannedInAvian.com
but it seems they always have to learn it for themselves.| Shae Matijs Erisson

Re: [Haskelldb-users] Release

[Bjorn B. <bri...@cs...>]

On Jul 17, 2006, at 1:14 PM, Matthias Radestock wrote:

> Bjorn Bringert <bri...@cs...> writes:
>
>> I think that some sort of test suite would be very nice to have
>> before a release, but that might just be my personal opinion.
>
> IMHO the test suite is *essential*. HaskellDB is quite a complex =20
> library
> and changes in one area can have far-reaching and non-obvious
> consequences. In absence of a large user base, a reasonably
> comprehensive test suite is crucial for tracking down bugs. I was
> horrified when I found out that the current test suite had
> bit-rotted. It means that all recent changes are highly suspect and =20=

> will
> have most likely broken something somewhere.
>
> Bjorn, do you know when the test suite was last run successfully? Then
> we could take a look what changes were introduced since then and add
> test cases for those. Ideally we'd also do coverage testing to =20
> determine
> what other tests we should add to get a reasonably good coverage of =20=

> the
> library.
>
> One added complication is that the test suite should be run against a
> variety of db backends, in order to identify db-specific code that has
> crept into the generic code base, and bugs in the db-specific code
> itself.

I don't think that it would be too hard to get the current tests =20
running again, but they were never that good:

- There has never been a time when all of them worked on all back-=20
ends, because of back-end incompatibilities.
- The coverage is probably quite poor.
- Many of them don't check their outputs, they mostly just test that =20
HaskellDB doesn't generate bad SQL or crash in some other way.

Some ideas for getting a good test suite together:

- Design a test database and write DBInfo for it.

- Use DynConnect for database connections. Extend DynConnect to =20
support all driver (missing HDBC drivers at the moment)

- Have some way for the user to provide connection parameters to all =20
the database back-ends to test with.

- Use HUnit, and maybe even QuickCheck.

- Maybe the FlatDB [1] backend could be used as a reference. It's a =20
simple database back-end whose query language is HaskellDB's internal =20=

PrimQuery type.


One of the reasons that this hasn't been done yet is that the back-=20
end incompatibility problem is so frustrating. But a test suite would =20=

be a good way to identify the things that need to be taken care of by =20=

any back-end specific SQL generation.

I can try to get a test framework together. Are there any volunteers =20
who would like to contribute test DB layout, data, unit tests or =20
QuickCheck properties?

/Bj=F6rn

[1] http://www.cs.chalmers.se/~bringert/darcs/haskelldb-flat/

Re: [Haskelldb-users] Release

[Matthias R. <mat...@so...>]

Bjorn Bringert <bri...@cs...> writes:

> I think that some sort of test suite would be very nice to have  
> before a release, but that might just be my personal opinion.

IMHO the test suite is *essential*. HaskellDB is quite a complex library
and changes in one area can have far-reaching and non-obvious
consequences. In absence of a large user base, a reasonably
comprehensive test suite is crucial for tracking down bugs. I was
horrified when I found out that the current test suite had
bit-rotted. It means that all recent changes are highly suspect and will
have most likely broken something somewhere.

Bjorn, do you know when the test suite was last run successfully? Then
we could take a look what changes were introduced since then and add
test cases for those. Ideally we'd also do coverage testing to determine
what other tests we should add to get a reasonably good coverage of the
library.

One added complication is that the test suite should be run against a
variety of db backends, in order to identify db-specific code that has
crept into the generic code base, and bugs in the db-specific code
itself.


Matthias.

Re: [Haskelldb-users] Release

[Bjorn B. <bri...@cs...>]

On Jul 17, 2006, at 12:15 PM, Henning G=FCnther wrote:

> Hi,
>
> as a volunteer worker for the Gentoo Linux Haskell Team, I'd like =20
> to ask
> you about the chances for a release of HaskellDB. As your project
> includes very interesting methods for database access, I'd be glad if
> your developments could be shared with the Gentoo Community.
> As it states "your help is very welcome" on your homepage, I'd like to
> know, what kind of help you're thinking of to get a release done.

I think that some sort of test suite would be very nice to have =20
before a release, but that might just be my personal opinion. There =20
are also open bugs [1] and missing features [2], but those have been =20
around for a long time, and we still have some users. I guess I don't =20=

really see any reason why there couldn't be a 0.10 release at this =20
point. I'll see what I can do.

/Bj=F6rn

[1] http://sourceforge.net/tracker/?group_id=3D101095&atid=3D629040

[2] http://sourceforge.net/tracker/?group_id=3D101095&atid=3D629043

[Haskelldb-users] Release

[Henning <h.g...@tu...>]

Hi,

as a volunteer worker for the Gentoo Linux Haskell Team, I'd like to ask
you about the chances for a release of HaskellDB. As your project
includes very interesting methods for database access, I'd be glad if
your developments could be shared with the Gentoo Community.
As it states "your help is very welcome" on your homepage, I'd like to
know, what kind of help you're thinking of to get a release done.

Re: [Haskelldb-users] insertQuery and default values

[Bjorn B. <bri...@cs...>]

On Jul 12, 2006, at 3:02 PM, Matthias Radestock wrote:

>
> How can I insert rows into a table with some column values coming =20
> from a
> query and the rest being set to their defaults?
>
> insertQuery generates SQL of the form
>
>   INSERT INTO table (SELECT ...)
>
> This doesn't allow default values to be specified because a) the =20
> SELECT
> must produce as many columns as there are in the table, b) it is =20
> illegal
> to write something like 'SELECT DEFAULT,..'.
>
> By contrast
>
>   INSERT INTO table(column,...) (SELECT ...)
>
> will give default values to all the columns that do not appear in the
> column list. However, from my experimenting and looking at the code it
> appears that there is currently no way to construct such a query.
>
> Would it be possible to add this? I suspect one difficulty might be
> expressing the record typing constraints required to make this =20
> operation
> safe.

HaskellDB's support for using default values is not very good. I =20
think that we would need a subtyping relation on records to implement =20=

this properly.

You will find that there are more things missing, like left joins. I =20
usually just fake whatever is missing using Haskell code, but that is =20=

of course less efficient.

I am starting to think that HaskellDB needs a serious overhaul to fix =20=

problems like this, and address back-end incompatibilities. I just =20
need to find the time to do it.

/Bj=F6rn

[Haskelldb-users] insertQuery and default values

[Matthias R. <mat...@so...>]

How can I insert rows into a table with some column values coming from a
query and the rest being set to their defaults?

insertQuery generates SQL of the form

  INSERT INTO table (SELECT ...)

This doesn't allow default values to be specified because a) the SELECT
must produce as many columns as there are in the table, b) it is illegal
to write something like 'SELECT DEFAULT,..'.

By contrast

  INSERT INTO table(column,...) (SELECT ...)

will give default values to all the columns that do not appear in the
column list. However, from my experimenting and looking at the code it
appears that there is currently no way to construct such a query.

Would it be possible to add this? I suspect one difficulty might be
expressing the record typing constraints required to make this operation
safe.


Matthias

Re: [Haskelldb-users] composing relational operations with aggregate expressions

[Bjorn B. <bri...@cs...>]

On Jul 11, 2006, at 3:33 PM, Matthias Radestock wrote:

> Bjorn Bringert <bri...@cs...> writes:
>
>> Try changing line 187 in Optimize.hs to
>>
>>           	=3D not (any (isAggregate.snd) assoc)
>>
>> Let me know if that helps and I'll fix it in darcs.
>
> That seems to do the trick. Thanks! I now get
>
> SELECT DISTINCT count6 as count
> FROM  (SELECT DISTINCT COUNT(id5) as count6
>        FROM  ((SELECT DISTINCT id as id5
>                FROM  table1 as T1)
>               EXCEPT
>               (SELECT DISTINCT id as id5
>                FROM  table2 as T1)) as T1) as T1
>
> The outer select is unnecessary but harmless.

Thank you for the report, the change is in darcs now.

/Bj=F6rn

Re: [Haskelldb-users] composing relational operations with aggregate expressions

[Matthias R. <mat...@so...>]

Bjorn,

Bjorn Bringert <bri...@cs...> writes:

> Try changing line 187 in Optimize.hs to
>
>           	= not (any (isAggregate.snd) assoc)
>
> Let me know if that helps and I'll fix it in darcs.

That seems to do the trick. Thanks! I now get

SELECT DISTINCT count6 as count
FROM  (SELECT DISTINCT COUNT(id5) as count6
       FROM  ((SELECT DISTINCT id as id5
               FROM  table1 as T1)
              EXCEPT
              (SELECT DISTINCT id as id5
               FROM  table2 as T1)) as T1) as T1

The outer select is unnecessary but harmless.


Matthias

Re: [Haskelldb-users] composing relational operations with aggregate expressions

[Bjorn B. <bri...@cs...>]

On Jul 11, 2006, at 2:38 PM, Matthias Radestock wrote:

> I am trying to construct a haskelldb query that returns the count =20
> of the
> ids in one table that are not present in another table. Here's what I
> came up with:
>
> test1Query =3D
>     do t <- table Table1.table1
>        project (idField << t1!Table1.xid)
>
> test2Query =3D
>     do t <- table Table2.table2
>        project (idField << t2!Table2.xid)
>
> test3Query =3D
>     do ids <- minus test1Query test2Query
>        project (countField << count (ids!idField))
>
> Unfortunately this is not producing the right SQL. showSql returns
>
> (SELECT DISTINCT COUNT(id) as count
>  FROM  table1 as T1)
> EXCEPT
> (SELECT DISTINCT COUNT(id) as count
>  FROM  table2 as T1)
>
> The same happens for other combinations of relational operations with
> aggregate expressions, e.g. 'union' combined with '_min'. In all cases
> the aggregate expression gets pushed under the relational operation,
> which is just plain wrong.
>
> Am I not constructing my queries the right way or is this a bug?

That sure seems like a bug. Try changing line 187 in Optimize.hs to

           	=3D not (any (isAggregate.snd) assoc)

Let me know if that helps and I'll fix it in darcs.

> Matthias.
> PS: Is the haskelldb bug tracker at
> http://sourceforge.net/tracker/?group_id=3D101095&atid=3D629040 still =
in
> use? There hasn't been any activity on it for nearly 18 months.

It's still in use in the sense that most of those bugs still haven't =20
been fixed. It's not in use in the sense that noone has reported any =20
new bugs since then. It's basically a result of the lack of users and =20=

releases. Which in turn probably depends on a lack of developer time. =20=

Basically we would only enter stuff there if it couldn't be fixed =20
right away.

/Bj=F6rn

Re: [Haskelldb-users] composing relational operations with aggregate expressions

[Matthias R. <mat...@so...>]

Matthias Radestock <mat...@so...> writes:

> test1Query =
>     do t <- table Table1.table1
>        project (idField << t1!Table1.xid)
>
> test2Query =
>     do t <- table Table2.table2
>        project (idField << t2!Table2.xid)

Small correction: The projections should read ... <<t!....


Matthias.

[Haskelldb-users] composing relational operations with aggregate expressions

[Matthias R. <mat...@so...>]

I am trying to construct a haskelldb query that returns the count of the
ids in one table that are not present in another table. Here's what I
came up with:

test1Query =
    do t <- table Table1.table1
       project (idField << t1!Table1.xid)

test2Query =
    do t <- table Table2.table2
       project (idField << t2!Table2.xid)

test3Query =
    do ids <- minus test1Query test2Query
       project (countField << count (ids!idField))

Unfortunately this is not producing the right SQL. showSql returns

(SELECT DISTINCT COUNT(id) as count
 FROM  table1 as T1)
EXCEPT
(SELECT DISTINCT COUNT(id) as count
 FROM  table2 as T1)

The same happens for other combinations of relational operations with
aggregate expressions, e.g. 'union' combined with '_min'. In all cases
the aggregate expression gets pushed under the relational operation,
which is just plain wrong.

Am I not constructing my queries the right way or is this a bug?


Matthias.
PS: Is the haskelldb bug tracker at
http://sourceforge.net/tracker/?group_id=101095&atid=629040 still in
use? There hasn't been any activity on it for nearly 18 months.

Re: [Haskelldb-users] DBDirect error

[Bjorn B. <bri...@cs...>]

Original question, for reference:

> running DBDirect gives me  the following error message
>
> DBDirect: user error (Couldn't load
> Database.HaskellDB.HSQL.PostgreSQL.driver from package
> haskelldb-hsql-postgresql-0.9)
>
> Any idea on what is the problem and how I can fix it?
>
> I am using ghc 6.5.20060608, on a intel macbook.


>> Hi Georgos,
>>
>> did you install the haskelldb-hsql-postgresql package? What does =20
>> "ghc-
>> pkg list" show?
>
> Hi Bj=F6rn,
>
> I have installed the package, the list of the installed packages is
> the following:
>
> /usr/local/lib/ghc-6.5.20060608/package.conf:
>    ALUT-2.0, Cabal-1.1.4, GLUT-2.0, HDBC-1.0.0,
>    HDBC-postgresql-1.0.0.0, HGL-3.1, HUnit-1.1, OpenGL-2.1,
>    QuickCheck-1.0, X11-1.1, base-1.0, fgl-5.2, fps-0.7,
>    (ghc-6.5.20060608), haskell-src-1.0, haskell98-1.0, haskelldb-0.9,
>    haskelldb-dynamic-0.9, haskelldb-hdbc-0.9,
>    haskelldb-hdbc-postgresql-0.9, haskelldb-hsql-0.9,
>    haskelldb-hsql-postgresql-0.9, hsql-1.7, hsql-odbc-1.7,
>    hsql-postgresql-1.7, mtl-1.0, network-1.0, parsec-2.0, plugins-1.0,
>    readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, time-0.3.1,
>    unix-1.0
>
> Any other idea of what the problem might be?

First, I forgot to ask which version of HaskellDB you have. You =20
should be running the current darcs version.

I think that the first thing to do is to investigate whether hs-=20
plugins works on your machine.

/Bj=F6rn=

Re: [Haskelldb-users] DBDirect error

[Georgos S. <si...@gm...>]

> Hi Georgos,
>
> did you install the haskelldb-hsql-postgresql package? What does "ghc-
> pkg list" show?

Hi Bj=F6rn,

I have installed the package, the list of the installed packages is
the following:

/usr/local/lib/ghc-6.5.20060608/package.conf:
    ALUT-2.0, Cabal-1.1.4, GLUT-2.0, HDBC-1.0.0,
    HDBC-postgresql-1.0.0.0, HGL-3.1, HUnit-1.1, OpenGL-2.1,
    QuickCheck-1.0, X11-1.1, base-1.0, fgl-5.2, fps-0.7,
    (ghc-6.5.20060608), haskell-src-1.0, haskell98-1.0, haskelldb-0.9,
    haskelldb-dynamic-0.9, haskelldb-hdbc-0.9,
    haskelldb-hdbc-postgresql-0.9, haskelldb-hsql-0.9,
    haskelldb-hsql-postgresql-0.9, hsql-1.7, hsql-odbc-1.7,
    hsql-postgresql-1.7, mtl-1.0, network-1.0, parsec-2.0, plugins-1.0,
    readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, time-0.3.1,
    unix-1.0

Any other idea of what the problem might be?

> > Also, can anyone tell me how i can generate the documentation using
> > haddock, so that I have a single index file for all the haskelldb
> > packages.
>
> Hmm, good question. You can't use Cabal's haddock command for that. I
> added a Makefile with a 'haddock'  target which builds haddock docs
> in doc/api. Just pull the current darcs version and run:
>
> $ make haddock

Thanks, for the prompt reply and the makefile,
Georgos

Re: [Haskelldb-users] DBDirect error

[Bjorn B. <bri...@cs...>]

On Jul 11, 2006, at 12:07 PM, Georgos Siganos wrote:

> Hi all,
> running DBDirect gives me  the following error message
>
> DBDirect: user error (Couldn't load
> Database.HaskellDB.HSQL.PostgreSQL.driver from package
> haskelldb-hsql-postgresql-0.9)
>
> Any idea on what is the problem and how I can fix it?
>
> I am using ghc 6.5.20060608, on a intel macbook.

Hi Georgos,

did you install the haskelldb-hsql-postgresql package? What does "ghc-=20=

pkg list" show?

> Also, can anyone tell me how i can generate the documentation using
> haddock, so that I have a single index file for all the haskelldb
> packages.

Hmm, good question. You can't use Cabal's haddock command for that. I =20=

added a Makefile with a 'haddock'  target which builds haddock docs =20
in doc/api. Just pull the current darcs version and run:

$ make haddock

/Bj=F6rn

[Haskelldb-users] DBDirect error

[Georgos S. <si...@gm...>]

Hi all,
running DBDirect gives me  the following error message

DBDirect: user error (Couldn't load
Database.HaskellDB.HSQL.PostgreSQL.driver from package
haskelldb-hsql-postgresql-0.9)

Any idea on what is the problem and how I can fix it?

I am using ghc 6.5.20060608, on a intel macbook.

Also, can anyone tell me how i can generate the documentation using
haddock, so that I have a single index file for all the haskelldb
packages.

Best Regards,
Georgos

Re: [Haskelldb-users] 'IN' operator

[Bjorn B. <bri...@cs...>]

On Jul 10, 2006, at 4:37 AM, Matthias Radestock wrote:

> I found a bug in the '_in' implementation: The empty-list case =20
> needs to
> be handled specially since SQL (well, postgresql at least) barfs when
> you feed it the expression "...IN ()".

Thank you! I fixed this by introducing some expression optimization =20
with should get rid of some delete, update and restrict criteria =20
whose values are statically known. Again, this is pretty untested so =20
it may eat your database (this is actually a real risk, since the =20
changes affect delete and update).

/Bj=F6rn