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

Re: [Haskelldb-users] Demo

[Conny A. <for...@dt...>]

On l=C3=B6r, 2004-05-22 at 16:28 +0100, Robert Wills wrote:
> Hello,
>=20
> Is there a username, password for testing the Demo at
> http://jackass.tekno.chalmers.se/dp03-7/cgi/run ?
>=20
> Sorry if I'm being dense but I couldn't see anything about how to log in
> to see the forum in action.
>=20
> -Rob
>=20
Thank you for testing our demo application.

Sorry for not having this information on the website.

Login:		guest
Password:	guest=20

Hopefully the homepage will be updated soon.

--=20
//
  Conny Andersson
  for...@dt...

[Haskelldb-users] Demo

[Robert W. <rob...@di...>]

Hello,

Is there a username, password for testing the Demo at
http://jackass.tekno.chalmers.se/dp03-7/cgi/run ?

Sorry if I'm being dense but I couldn't see anything about how to log in
to see the forum in action.

-Rob

[Haskelldb-users] Demo

[Robert W. <rob...@di...>]

Hello,

Is there a username, password for testing the Demo at
http://jackass.tekno.chalmers.se/dp03-7/cgi/run ?

Sorry if I'm being dense but I couldn't see anything about how to log in
to see the forum in action.

-Rob

[Haskelldb-users] HaskellDB no longer an auto package

[Bjorn B. <d00...@dt...>]

Hi,

HaskellDB was an auto package in ghc (that is, you did not have to use
-package haskelldb) up til today. Starting with tomorrow's CVS snapshot,
it is not. The reason is that since haskelldb requires -fglasgow-exts,
that flag would always be turned on whether haskelldb was used or not.
This caused problems for some users.

This means that in the future, you will have to use "-package haskelldb"
when compiling HaskellDB programs.

/Bj=F6rn Bringert

Re: [Haskelldb-users] Querying an empty table

[Bjorn B. <d00...@dt...>]

Gregory Wright wrote:
> I tried the suggest method and it didn't typecheck. (_case requires Expr,
> not ExprAggr). This seems unnecessarily restrictive; I would expect _case
> to be able to take both an Expr and ExprAggr in the conditional position.

Of course! Silly me. Allowing Expr or ExprAggr in the conditional is not 
enough,
we would have to allow both of them in the result psotions too. This seems
difficult to type correctly.

_case :: ProjectExpr e => [(e Bool, e a)] -> e a -> e a

should work, but then all the expressions have to be of the same type, 
can't mix
aggregate and non-aggregate expressions.

> For my program I have a workaround, but in developing it I ran into an
> interesting question.  (The workaround is just to query the count first,
> and if it is nonzero query for the maximum element.)
> 
> Assume I have a database with a single table, all of whose fields are 
> Strings. In hdb, how can I count the number of records matching a condition? The
> query would look something like
> 
> myquery = do
>         t  <- table mytab
>         restrict (t!myfield .==. constant the_interesting_field_value)
>         u <- project ( <this is the problem>  << count(t!myfield))
>         return u
> 
> The projection is where the trouble is again. (I understand that I could
> return the entire list of match records and take the length, but if the 
> list is long and all I want is the count, that is unreasonably inefficient.)
> 
> Since we don't have a field of type Int, how do we return the count?

This is a known problem, and we don't have a solution for it. It is a 
consequence
of our implementation of record types. See below for a workaround.


> The solution may be straightforward, since we just need a way to easily 
> make a record with known fields. Something like
> 
>         project(returnAs("foo", IntT, True) << count(t!myfield))
> 
> which would result in the query
> 
>         SELECT COUNT(myfield) AS foo ...
> 
> This could also solve the problem of _max and _min returning nothing on
> empty tables, if the column named in returnAs were nullable.

The problem with this approach is that it cannot be type checked.


> Is it possible to declare a fake table (not present in the database) and
> use it as a field in project? Then I could say
> 
>         project (fakecol << count(t!myfield))
> 
> where fakecol was a column of type nullable Int. That might would be
> easy, and it would be easy to explain that DBDirect automatically made
> row declarations for each table in the database, but to return synthetic
> rows you have to declare them yourself.

The best workaround that we know of is to declare fake
fields, as you describe. test/CustomSql.hs has some examples of fake fields.

Here's how to declaare a field foo with type Int:

     data Foo = Foo
     instance FieldTag Foo where fieldName _ = "foo"
     foo = mkAttr Foo :: Attr Foo Int


If you are using ghc you can use Template Haskell to declare fake fields by
using test/THField.hs:

import Dp037.D3proj_time_reports
import THField

$(field "foo" "foo" "Foo" False "Int")

q = do
     t <- table d3proj_time_reports
     project (foo << count(t!userid))

The interesting function is:

-- | Declare a field.
field :: String  -- ^ Haskell identifier for the field (e.g. "xid")
       -> String  -- ^ Actual field name (e.g. "id")
       -> String  -- ^ Name of the field label type (e.g. "Id")
       -> Bool    -- ^ Whether the field is nullable
       -> String  -- ^ Name of the value type of the field (e.g. "Int")
       -> Q [Dec]

/Bjorn

Re: [Haskelldb-users] Querying an empty table

[Gregory W. <gw...@co...>]

Hi Bjorn,

I tried the suggest method and it didn't typecheck. (_case requires 
Expr,
not ExprAggr). This seems unnecessarily restrictive; I would expect 
_case
to be able to take both an Expr and ExprAggr in the conditional 
position.

For my program I have a workaround, but in developing it I ran into an
interesting question.  (The workaround is just to query the count first,
and if it is nonzero query for the maximum element.)

Assume I have a database with a single table, all of whose fields are 
Strings.
In hdb, how can I count the number of records matching a condition? The
query would look something like

myquery = do
         t  <- table mytab
         restrict (t!myfield .==. constant the_interesting_field_value)
         u <- project ( <this is the problem>  << count(t!myfield))
         return u

The projection is where the trouble is again. (I understand that I could
return the entire list of match records and take the length, but if the 
list
is long and all I want is the count, that is unreasonably inefficient.)

Since we don't have a field of type Int, how do we return the count?

The solution may be straightforward, since we just need a way to easily 
make
a record with known fields. Something like

         project(returnAs("foo", IntT, True) << count(t!myfield))

which would result in the query

         SELECT COUNT(myfield) AS foo ...

This could also solve the problem of _max and _min returning nothing on
empty tables, if the column named in returnAs were nullable.

Is it possible to declare a fake table (not present in the database) and
use it as a field in project? Then I could say

         project (fakecol << count(t!myfield))

where fakecol was a column of type nullable Int. That might would be
easy, and it would be easy to explain that DBDirect automatically made
row declarations for each table in the database, but to return synthetic
rows you have to declare them yourself.

  Thank for your help.

Best Wishes,
Greg



On May 9, 2004, at 7:21 PM, Bjorn Bringert wrote:

> Gregory Wright wrote:
>> I have a question about how to query an empty table. (I have to query 
>> the
>> table to find the maximum value of a field; if there are any entries 
>> at all the
>> field is non-null.)
>> I used
>> last  = do
>>             events <- table event
>>             restrict (events!sid .==. constant 1)
>>             u <- project (cid << _max(events!cid))
>>             return u
>> The fields are sid and cid, and the goal is to find the largest value
>> of cid. Since cid is non-null as a type, this gives an error if the 
>> table
>> is empty.
>> If there are any entries at all in the table, there are over 100,000,
>> so I don't want to return the whole table just to see if it is 
>> non-empty.
>> My question: is there a way to simply have the query return empty
>> list if the table is empty, in a way that typechecks, or
>
> You have found an problem is HaskellDB's type system that I don't think
> we were aware of. The result type of _max, _min, avg etc. should be 
> nullable,
> since they seem to return NULL if the relation is empty. We'll look 
> into that.
>
> One way of solving your problem is to do something like (not tested):
>
> -- return the max value of the expression, or 0 if the relation is 
> empty
> safeMax e = _case [(count e .>. 0, _max e)] (constant 0)
>
> last  = do
>             events <- table event
>             restrict (events!sid .==. constant 1)
>             u <- project (cid << safeMax (events!cid))
>             return u
>

Re: [Haskelldb-users] Querying an empty table

[Gregory W. <gw...@co...>]

On May 9, 2004, at 7:21 PM, Bjorn Bringert wrote:

> Gregory Wright wrote:
>> I have a question about how to query an empty table. (I have to query 
>> the
>> table to find the maximum value of a field; if there are any entries 
>> at all the
>> field is non-null.)
>> I used
>> last  = do
>>             events <- table event
>>             restrict (events!sid .==. constant 1)
>>             u <- project (cid << _max(events!cid))
>>             return u
>> The fields are sid and cid, and the goal is to find the largest value
>> of cid. Since cid is non-null as a type, this gives an error if the 
>> table
>> is empty.
>> If there are any entries at all in the table, there are over 100,000,
>> so I don't want to return the whole table just to see if it is 
>> non-empty.
>> My question: is there a way to simply have the query return empty
>> list if the table is empty, in a way that typechecks, or
>
> You have found an problem is HaskellDB's type system that I don't think
> we were aware of. The result type of _max, _min, avg etc. should be 
> nullable,
> since they seem to return NULL if the relation is empty. We'll look 
> into that.
>
> One way of solving your problem is to do something like (not tested):
>
> -- return the max value of the expression, or 0 if the relation is 
> empty
> safeMax e = _case [(count e .>. 0, _max e)] (constant 0)
>
> last  = do
>             events <- table event
>             restrict (events!sid .==. constant 1)
>             u <- project (cid << safeMax (events!cid))
>             return u
>

I'll give that a try in the morning. (I have to give baby a bath now.)


>
>> is it just as efficient to do a lazy query (no "project"), see if the 
>> head
>> is non-empty and then repeat the query with the projection? Or is
>> there some better way of structuring this that I haven't learned yet?
>
> In theory, the lazy approach should work, but there are problems with 
> the
> implementation of lazy queries which would make this inefficient.
>
>> By the way, the previous advice about using _default for 
>> auto-increment
>> fields works perfectly with PostgreSQL v. 7.4.2. Thanks for the hint. 
>> I'm
>> slowly getting better at finding examples in the test programs but
>> I'm still very much an HDB newbie.
>
> Requiring users to plow through undocumented demo programs to find 
> anything but
> the basic features is not very good. Mary is working on a tutorial, 
> but I'm guessing
> that she probably won't get to features like auto increment columns 
> for a while.
> You are welcome to contribute things that you find out to the 
> AvianWiki tutorial
> that is linked from the haskelldb web site.
>

I will do that!  I appreciate your generous help: thank you and get 
some sleep!

Best,
Greg


> /Bjorn
>

Re: [Haskelldb-users] Querying an empty table

[Bjorn B. <d00...@dt...>]

Gregory Wright wrote:
> I have a question about how to query an empty table. (I have to query the
> table to find the maximum value of a field; if there are any entries at 
> all the
> field is non-null.)
> 
> I used
> 
> last  = do
>             events <- table event
>             restrict (events!sid .==. constant 1)
>             u <- project (cid << _max(events!cid))
>             return u
> 
> 
> The fields are sid and cid, and the goal is to find the largest value
> of cid. Since cid is non-null as a type, this gives an error if the table
> is empty.
> 
> If there are any entries at all in the table, there are over 100,000,
> so I don't want to return the whole table just to see if it is non-empty.
> 
> My question: is there a way to simply have the query return empty
> list if the table is empty, in a way that typechecks, or

You have found an problem is HaskellDB's type system that I don't think
we were aware of. The result type of _max, _min, avg etc. should be 
nullable,
since they seem to return NULL if the relation is empty. We'll look into 
that.

One way of solving your problem is to do something like (not tested):

-- return the max value of the expression, or 0 if the relation is empty
safeMax e = _case [(count e .>. 0, _max e)] (constant 0)

last  = do
             events <- table event
             restrict (events!sid .==. constant 1)
             u <- project (cid << safeMax (events!cid))
             return u


> is it just as efficient to do a lazy query (no "project"), see if the head
> is non-empty and then repeat the query with the projection? Or is
> there some better way of structuring this that I haven't learned yet?

In theory, the lazy approach should work, but there are problems with the
implementation of lazy queries which would make this inefficient.

> By the way, the previous advice about using _default for auto-increment
> fields works perfectly with PostgreSQL v. 7.4.2. Thanks for the hint. I'm
> slowly getting better at finding examples in the test programs but
> I'm still very much an HDB newbie.

Requiring users to plow through undocumented demo programs to find 
anything but
the basic features is not very good. Mary is working on a tutorial, but 
I'm guessing
that she probably won't get to features like auto increment columns for 
a while.
You are welcome to contribute things that you find out to the AvianWiki 
tutorial
that is linked from the haskelldb web site.

/Bjorn

[Haskelldb-users] Querying an empty table

[Gregory W. <gw...@co...>]

Hi,

I have a question about how to query an empty table. (I have to query 
the
table to find the maximum value of a field; if there are any entries at 
all the
field is non-null.)

I used

last  = do
             events <- table event
             restrict (events!sid .==. constant 1)
             u <- project (cid << _max(events!cid))
             return u


The fields are sid and cid, and the goal is to find the largest value
of cid. Since cid is non-null as a type, this gives an error if the 
table
is empty.

If there are any entries at all in the table, there are over 100,000,
so I don't want to return the whole table just to see if it is 
non-empty.

My question: is there a way to simply have the query return empty
list if the table is empty, in a way that typechecks, or

is it just as efficient to do a lazy query (no "project"), see if the 
head
is non-empty and then repeat the query with the projection? Or is
there some better way of structuring this that I haven't learned yet?

By the way, the previous advice about using _default for auto-increment
fields works perfectly with PostgreSQL v. 7.4.2. Thanks for the hint. 
I'm
slowly getting better at finding examples in the test programs but
I'm still very much an HDB newbie.

Best Wishes,

Greg

Gregory Wright
Antiope Assoicates LLC
gw...@an...

Re: [Haskelldb-users] best way to implement this query?

[Bjorn B. <d00...@dt...>]

Bjorn Bringert wrote:

> One way could be to join the table with itself (the most efficient thing 
> in the world, though):

Make that "NOT the most efficient thing in the world".

/Bjorn, who should go to bed

Re: [Haskelldb-users] best way to implement this query?

[Bjorn B. <d00...@dt...>]

Jeremy Shaw wrote:
> Hello,
> 
> I am not quite sure what the best way to do the following in
> haskelldb is:
> 
> Here is the query in SQL:
> 
> select column1 from table1 where column2 = (select max(column2) from 
> table1);
> 
> Basically, I want to find the value in column1 that is in the same
> row as the maximum column2 value. In this case, column2 is a unique
> key.
> 
> I could do this as two seperate queries haskelldb,  one to find the
> max column2 value, and a second query to find the corresponding
> column1 value -- but it would be nice to do it all in one step. I
> imagine I might also be able to hack something up by using sort and
> top -- but that seems a bit hackish when the actual SQL I want to 
> generate is pretty straight forward.
> 
> Any ideas?

One way could be to join the table with itself (the most efficient thing 
in the world, though):

do
   t <- table table1
   t' <- table table1
   r <- project (column2 << _max (t'!column2))
   restrict (t!column2 .==. r!column2)
   project (column1 << t!column1)


I think being able to use queries in expressions is a todo item left over
from the original HaskellDB.

It would be nice if something like this would work:

do
   t <- table table1
   let m = do
                t' <- table table1
                project (column2 << _max (t'!column2))
   restrict (column2 `_in` m)
   project (column1 << t!column1)

That is, we would have a function:

_in :: Eq a => Expr a -> Query (Rel (RecCons f a RecNil)) -> Expr Bool

That doesn't actually work, since the result should be in the Query monad,
but something along these lines should be doable.

/Bjorn

[Haskelldb-users] best way to implement this query?

[Jeremy S. <Jer...@li...>]

Hello,

 I am not quite sure what the best way to do the following in haskelldb
 is:

Here is the query in SQL:

 select column1 from table1 where column2 =3D (select max(column2) from
 table1);

 Basically, I want to find the value in column1 that is in the same row
 as the
maximum column2 value. In this case, column2 is a unique key.

 I could do this as two seperate queries haskelldb,=C2=A0 one to find the m=
ax
 column2 value,
 and a second query to find the corresponding column1 value -- but it
 would be nice to
 do it all in one step. I imagine I might also be able to hack something
 up by using sort
 and top -- but that seems a bit hackish when the actual SQL I want to
 generate is
pretty straight forward.

Any ideas?

Thanks!
Jeremy Shaw.

Re: [Haskelldb-users] Problem with hdb and postgresql

[Bjorn B. <d00...@dt...>]

Gregory Wright wrote:
> This is in 0.8 or a snapshot?

It's in 0.8 (I think it was first introduced in 0.7).

/Bjorn

> On May 7, 2004, at 8:45 PM, Bjorn Bringert wrote:
>> We added the Query._default construct to deal with default values and
>> auto-increment colums. I belive that it works for SERIAL columns in 
>> PostgreSQL.
>> It can be used as an expression, for example:
>>
>> insert db my_table (my_serial_col << _default # other_col << constant 
>> "foobar")
>>
>> Let us know if it works for you.

Re: [Haskelldb-users] Problem with hdb and postgresql

[Gregory W. <gw...@co...>]

Hi Bjorn,

This is in 0.8 or a snapshot?

Thanks,
Greg


On May 7, 2004, at 8:45 PM, Bjorn Bringert wrote:

> Gregory Wright wrote:
>> I've been using HaskellDB to interface to a postgresql database and 
>> have come across a problem with "SERIAL" fields. In postgresql, a
>> SERIAL column is normally never written to but is automatically
>> assigned the next integer.  When read, the column is never empty, so
>> it is assigned the "non-null" attribute. (And therefore DBDirect
>> classifies it as not nullable.)
>> However, in normal use the column is never written to. So "non-null" 
>> in this case does not have its usual meaning of "must be present" in
>> an insert. In haskelldb however, failing to write the column causes a
>> type error, as positional parameters seem to be misaligned.
>> It is possible to work around this, but very inefficient. (The
>> maximum value of the SERIAL column can be read, and the next entry
>> can be written with max() + 1 into that field. But this involves
>> scanning the whole table for every insertion. It's not possible to
>> maintain the max value in the haskell program because it may not be
>> the only one to access the database.)
>> Is there some kind of simple way to fix this? I can imagine a record 
>> constructor that expands to nothing, allowing one to leave "non-null"
>>  fields empty in insertions. This could cause run time errors, but 
>> that's no worse than the situation now: if you write a non-unique 
>> value to a SERIAL, you get a run time error. Or should I just hack up
>> the output of DBDirect by hand, to make SERIAL fields nullable? This
>> has the drawback of returning them as (Maybe ...) in queries, when
>> they are really guaranteed to be non-null.
>> I admit that the use of many "SERIAL" fields is an ugly way to
>> structure the database (I didn't write the schema). But it seems that
>> schema that depend on autoincrementing values use them everywhere,
>> and they are very awkward to handle under the current haskelldb
>> arrangement.
>> Any ideas as to how I might proceed?
>
> We added the Query._default construct to deal with default values and
> auto-increment colums. I belive that it works for SERIAL columns in 
> PostgreSQL.
> It can be used as an expression, for example:
>
> insert db my_table (my_serial_col << _default # other_col << constant 
> "foobar")
>
> Let us know if it works for you.
>
> /Bjorn
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

Re: [Haskelldb-users] Problem with hdb and postgresql

[Bjorn B. <d00...@dt...>]

Gregory Wright wrote:
> I've been using HaskellDB to interface to a postgresql database and 
> have come across a problem with "SERIAL" fields. In postgresql, a
> SERIAL column is normally never written to but is automatically
> assigned the next integer.  When read, the column is never empty, so
> it is assigned the "non-null" attribute. (And therefore DBDirect
> classifies it as not nullable.)
> 
> However, in normal use the column is never written to. So "non-null" 
> in this case does not have its usual meaning of "must be present" in
> an insert. In haskelldb however, failing to write the column causes a
> type error, as positional parameters seem to be misaligned.
> 
> It is possible to work around this, but very inefficient. (The
> maximum value of the SERIAL column can be read, and the next entry
> can be written with max() + 1 into that field. But this involves
> scanning the whole table for every insertion. It's not possible to
> maintain the max value in the haskell program because it may not be
> the only one to access the database.)
> 
> Is there some kind of simple way to fix this? I can imagine a record 
> constructor that expands to nothing, allowing one to leave "non-null"
>  fields empty in insertions. This could cause run time errors, but 
> that's no worse than the situation now: if you write a non-unique 
> value to a SERIAL, you get a run time error. Or should I just hack up
> the output of DBDirect by hand, to make SERIAL fields nullable? This
> has the drawback of returning them as (Maybe ...) in queries, when
> they are really guaranteed to be non-null.
> 
> I admit that the use of many "SERIAL" fields is an ugly way to
> structure the database (I didn't write the schema). But it seems that
> schema that depend on autoincrementing values use them everywhere,
> and they are very awkward to handle under the current haskelldb
> arrangement.
> 
> Any ideas as to how I might proceed?

We added the Query._default construct to deal with default values and
auto-increment colums. I belive that it works for SERIAL columns in 
PostgreSQL.
It can be used as an expression, for example:

insert db my_table (my_serial_col << _default # other_col << constant 
"foobar")

Let us know if it works for you.

/Bjorn

Re: [Haskelldb-users] Problem with hdb and postgresql

[Gregory W. <gw...@co...>]

(Ungraciously replying to his own mail):

Having looked at the list archive I see that in March, Jeremy Shaw
had a similar issue with mySQL and solved it using something like
a fake nullable field. Does mySQL return non-null as an attribute of
its auto-increment fields? If so maybe there is a generic way to
fix this problem.

Best Wishes,
Greg


On May 7, 2004, at 11:31 AM, Gregory Wright wrote:

>
> Hi,
>
> I've been using HaskellDB to interface to a postgresql database and
> have come across a problem with "SERIAL" fields.
> In postgresql, a SERIAL column is normally never written to but
> is automatically assigned the next integer.  When read, the
> column is never empty, so it is assigned the "non-null" attribute. (And
> therefore DBDirect classifies it as not nullable.)
>
> However, in normal use the column is never written to. So "non-null"
> in this case does not have its usual meaning of "must be present"
> in an insert. In haskelldb however, failing to write the column causes
> a type error, as positional parameters seem to be misaligned.
>
> It is possible to work around this, but very inefficient. (The maximum
> value of the SERIAL column can be read, and the next entry can
> be written with max() + 1 into that field. But this involves scanning
> the whole table for every insertion. It's not possible to maintain the
> max
> value in the haskell program because it may not be the only one
> to access the database.)
>
> Is there some kind of simple way to fix this? I can imagine a record
> constructor that expands to nothing, allowing one to leave "non-null"
> fields empty in insertions. This could cause run time errors, but
> that's no worse than the situation now: if you write a non-unique
> value to a SERIAL, you get a run time error. Or should I just hack
> up the output of DBDirect by hand, to make SERIAL fields nullable?
> This has the drawback of returning them as (Maybe ...) in queries,
> when they are really guaranteed to be non-null.
>
> I admit that the use of many "SERIAL" fields is an ugly way to 
> structure
> the database (I didn't write the schema). But it seems that schema that
> depend on autoincrementing values use them everywhere, and they
> are very awkward to handle under the current haskelldb arrangement.
>
> Any ideas as to how I might proceed?
>
> Best Wishes,
> Greg
>
> Gregory Wright
> Antiope Associates LLC
> gw...@an...
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Problem with hdb and postgresql

[Gregory W. <gw...@co...>]

Hi,

I've been using HaskellDB to interface to a postgresql database and
have come across a problem with "SERIAL" fields.
In postgresql, a SERIAL column is normally never written to but
is automatically assigned the next integer.  When read, the
column is never empty, so it is assigned the "non-null" attribute. (And
therefore DBDirect classifies it as not nullable.)

However, in normal use the column is never written to. So "non-null"
in this case does not have its usual meaning of "must be present"
in an insert. In haskelldb however, failing to write the column causes
a type error, as positional parameters seem to be misaligned.

It is possible to work around this, but very inefficient. (The maximum
value of the SERIAL column can be read, and the next entry can
be written with max() + 1 into that field. But this involves scanning
the whole table for every insertion. It's not possible to maintain the
max
value in the haskell program because it may not be the only one
to access the database.)

Is there some kind of simple way to fix this? I can imagine a record
constructor that expands to nothing, allowing one to leave "non-null"
fields empty in insertions. This could cause run time errors, but
that's no worse than the situation now: if you write a non-unique
value to a SERIAL, you get a run time error. Or should I just hack
up the output of DBDirect by hand, to make SERIAL fields nullable?
This has the drawback of returning them as (Maybe ...) in queries,
when they are really guaranteed to be non-null.

I admit that the use of many "SERIAL" fields is an ugly way to structure
the database (I didn't write the schema). But it seems that schema that
depend on autoincrementing values use them everywhere, and they
are very awkward to handle under the current haskelldb arrangement.

Any ideas as to how I might proceed?

Best Wishes,
Greg

Gregory Wright
Antiope Associates LLC
gw...@an...

Re: [Haskelldb-users] possible bug in haskelldb

[Bjorn B. <d00...@dt...>]

Jeremy Shaw wrote:
> I may have discovered a bug in haskelldb. Here is a simplified version
> of the what is wrong -- I have not tested to see if the simplified
> version actually exhibits the bug.
> 
> Lets say table A has a column 'name' and table B has a column 'name'.
> 
> If I do something like:
> 
> import qualified MyDatabase.A as A
> import qualified MyDatabase.B as B
> 
> query = do a <- table A.a
> 	   b <- table B.b
> 	   project ( A.name << a!A.name #
> 		     B.name << b!B.name
>                    )
> 
> 
> 
> If I use the results of the query, b!B.name gets a!A.name's
> value[1]. If I change the project to:
> 
> 	   project ( B.name << b!B.name #
> 		     A.name << a!A.name 
>                    )
> 
> Then the a!A.name gets b!B.name's value.
> 
> [1] or maybe its the other way around, I don't remember.

You are right, it is definitely a bug. And a nasty one too.

This HaskellDB code:

q = do
     reports <- table R.d3proj_time_reports
     users <- table U.d3proj_users
     project (R.xid << reports!R.xid
	     # U.xid << users!U.xid)

Generates this SQL:

SELECT DISTINCT id1 as id,
                 id1 as id
FROM  (SELECT DISTINCT id as id2
        FROM  d3proj_users as T1) as T1,
       (SELECT DISTINCT id as id1
        FROM  d3proj_time_reports as T1) as T2

Of course the driver won't know which "id" field to get the value of. We 
are not sure
how to fix it. Suggestions are welcome. Simply using the fully qualified 
name everywhere,
e.g. "d3proj_time_reports.id" won't work, since you apparantely cannot 
use that
after AS.

Thanks for discovering this problem.

/Bjorn

[Haskelldb-users] ANNOUNCE: HaskellDB 0.8

[<ch...@dt...>]

We are pleased to announce the first beta release of our "remake" of 
HaskellDB, version 0.8. HaskellDB is available for download from 
http://haskelldb.sourceforge.net

HaskellDB is a Haskell library for expressing database queries and 
operations in a type safe and declarative way. HaskellDB compiles a 
relational algebra-like syntax into SQL, submits the operations to the 
database for processing, and returns the results as ordinary Haskell values.

The original version of HaskellDB was written by Daan Leijen and is 
available at http://www.haskell.org/haskellDB/. The implementation is 
based on his paper which can be found at: 
http://www.cs.uu.nl/people/daan/download/papers/dsec.ps

New in HaskellDB 0.8:
- Improved compatibility with Microsoft Access
- Internal restructuring of code
- DBDirect generated files are now cleaner and probably more portable
  across HaskellDB versions
- More test programs

NOTE: Due to changes in DBDirect, any files generated using the old 
version of HaskellDB may have to be regenerated.

The developers can be reached at has...@li... 
or on #haskelldb at irc.freenode.net.

/ The HaskellDB development team

[Haskelldb-users] possible bug in haskelldb

[Jeremy S. <jer...@li...>]

Hello,

I may have discovered a bug in haskelldb. Here is a simplified version
of the what is wrong -- I have not tested to see if the simplified
version actually exhibits the bug.

Lets say table A has a column 'name' and table B has a column 'name'.

If I do something like:

import qualified MyDatabase.A as A
import qualified MyDatabase.B as B

query = do a <- table A.a
	   b <- table B.b
	   project ( A.name << a!A.name #
		     B.name << b!B.name
                   )



If I use the results of the query, b!B.name gets a!A.name's
value[1]. If I change the project to:

	   project ( B.name << b!B.name #
		     A.name << a!A.name 
                   )

Then the a!A.name gets b!B.name's value.

[1] or maybe its the other way around, I don't remember.


In any case, is this a know bug? Am I doing something wrong?

If this simple case does not actually exhibit the behaviour I am
seeing, I can do some additional testing and figure out the test case
that does.

I am using the nightly snapshot from 20040502.

Thanks!
Jeremy Shaw.

--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

Re: [Haskelldb-users] bug in DBDirect in nightly snapshot 20040502

[<ch...@dt...>]

Jeremy Shaw wrote:

>Hello,
>
> I downloaded and install nightly snapshot 20040502. When I ran
> DBDirect, it created
> the Database.hs file and the Database directory, but it did not create
> the .hs files for
>any of the tables.
>
>The attached patch fixed the problem for me...
>
>Jeremy Shaw.
>  
>

Thanks. We fixed this yesterday. The patch should be in the next 
snapshot. Sorry about that.

Anders

[Haskelldb-users] bug in DBDirect in nightly snapshot 20040502

[Jeremy S. <Jer...@li...>]

Hello,

 I downloaded and install nightly snapshot 20040502. When I ran
 DBDirect, it created
 the Database.hs file and the Database directory, but it did not create
 the .hs files for
any of the tables.

The attached patch fixed the problem for me...

Jeremy Shaw.

--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

Re: [Haskelldb-users] Survey

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

Anders H=C3=B6ckersten <ch...@dt...> writes:

> - What is your name, and current occupation?

Shae Erisson, self-employed programmer and web developer.

> - What is your level of experience with Haskell?

About three years self taught experience, intermediate Haskeller

> - How did you first come into contact with HaskellDB?

I found Daan's page, desperately wanted it for my web dev jobs.

> - What do you use HaskellDB for? We would love to have a longer descripti=
on
>   of any projects you are working on, to prove that it really is used. :)

curryspondence:
http://shapr.homelinux.net/cgi-bin/wash/SearchML
darcs get http://shapr.homelinux.net/repos/curryspondence

I'm planning on adding HaskellDB support to lambdabot.
I'd like to do professional webdev in Haskell, nearly every webdev app requ=
ires
nicely abstracted database support.

> - Please rate (on a scale from 1-10) HaskellDB in these departments, also
>   * Features

9 - nearly perfect

>   * Ease of use

9 - nearly perfect

>   * Documentation

10 (I wrote some myself ;-)

>   * User Support

10: many problems were fixed just a few hours after I reported them
    my questions were always quickly answered on #haskelldb

> - What do you regard as HaskellDB's main strengths?

type checking generated SQL code
ability to use higher order queries

> - What do you regard as HaskellDB's main weaknesses?

can be verbose?
HaskellDB still needs more demo apps to gain a critical mass of users and
maintainers before the current projects ends.

> - How would you like to see HaskellDB improved on in the future?

I'd like to see per-backend optimization plugins

> - Any final comments you want to add?

HaskellDB rocks! keep up the good work!
--=20
Shae Erisson  -  putStr $ fix("HELLO\n"++)  -  http://www.ScannedInAvian.or=
g/
OSDir: Community building... interesting... what's the secret sauce?
Limi: Irresponsible sleep patterns.
-- Alexander Limi, one of the Plone founders http://osdir.com/Article199.ph=
tml

Re: [Haskelldb-users] Survey

[Jeremy S. <jer...@li...>]

Hello,

> Questions:
> 
> - What is your name, and current occupation?

Jeremy Shaw, Software Engineer.

> - What is your level of experience with Haskell?

I have two years of self-taught experience. I would rate myself as an
intermediate level user.

> - How did you first come into contact with HaskellDB?

I found Daan Leijen's original version around a year ago, and did a
trivial port to Hugs+FreeBSD+MySQL.

> - What do you use HaskellDB for? We would love to have a longer description
>   of any projects you are working on, to prove that it really is used. :)

Science - A simple web-base program for tracking my girlfried's daily
stats, such as body temperature. The original version ran under
Hugs+FreeBSD+MySQL, and was quite slow. The current version is
compiled with GHC 6.2, and is nice and quick.

Porcupine - A web-based collaboration tool. There is really a lot I
could say about this, but I don't even know where to begin. It will be
a bit like, bugzilla, cvs, and microsoft project all rolled into one,
with RSS feeds, instant messaging gateways, and capabilities based
security.

Autobuilder RSS feeds - At Lindows, we have an autobuilder which can
check source out of CVS and build it. After a package is built, the
autobuilder sends an email to let you know if it suceeded or
failed. It also includes some links to more details about the
build. However, I find the emails to be annoying, so I wrote an RSS
feed generator for the autobuilder. The RSS feed has several
advantages over the email solution:

(1) Subscription to a feed is all controlled via the RSS reader. The
    email solution currently has no automated way of subscribing or
    unsubscribing. You must actually type in SQL commands to be added
    or removed.

(2) Faster! The links to the extra meta data take you to some page
    that is really slow (written in perl). This same information is
    included directly in the RSS feed, so you don't even have to click
    on anything.

(3) Better history viewing - Because each package is in its own
    seperate feed, and not mixed up with all my other email, I can
    quickly view the build history for any package.



Automatically bug generator - Just last week, I used haskelldb in a
program that analyzed changes to an arch repository, and automatically
generated a bunch of bugs in bugzilla. This is a huge time saver.

Menu Mangler interface - Today I will be starting a web-based
programming for populating the menu mangler database. The menu mangler
is a program that takes .debs and rearranges their menu entries. The
web interface will allow you to add override information to the menu
mangler database.

JiffyBooks - This weekend, I will be starting a web-based alternative
to QuickBooks for my own use.

> - Please rate (on a scale from 1-10) HaskellDB in these departments, also
>   include any comments you may have on the areas here:
>   * Features
>   * Ease of use
>   * Documentation
>   * User Support

> - What do you regard as HaskellDB's main strengths?

(1) strong type-checking 
(2) I like writing haskell code instead of SQL

> - What do you regard as HaskellDB's main weaknesses?

The very long error messages generated when you have a minor type errors in a query, insert, update, etc.

> - How would you like to see HaskellDB improved on in the future?

It would be cool if it could use template haskell to query the
database type interface at compile-time instead of having to use
DBDirect. Of course, this would not always be better, and it is also
GHC specific.

> - Any final comments you want to add?

My writing skills today really suck. If you actually want to use
anything I have written, verbatim, let me know and I will send you a
better written version.

> /Anders

[Haskelldb-users] Survey

[<ch...@dt...>]

Hi everyone! As some of you are aware, the project deadline (our work on
HaskellDB is a school project) for HaskellDB is drawing near. As part
of that, we are writing some documentation on what it is, how we have
structured the project and so on.

In this report, we would like to include some opinions from our users. We
figure a nice way of doing this would be through conducting an interview 
with
some of you. I have written down some questions below, and it would help us
greatly if you could take some time to answer them.

Oh, and while positive feedback is always nice, I am a big fan of
negative feedback too, so be sure to voice any complaints you have. :)
All questions are of course voluntary, you do not have to answer all of
them. You can be anonymous in the final report if you like (it will
probably be published on the Internet).

Questions:

- What is your name, and current occupation?

- What is your level of experience with Haskell?

- How did you first come into contact with HaskellDB?

- What do you use HaskellDB for? We would love to have a longer description
  of any projects you are working on, to prove that it really is used. :)

- Please rate (on a scale from 1-10) HaskellDB in these departments, also
  include any comments you may have on the areas here:
  * Features
  * Ease of use
  * Documentation
  * User Support

- What do you regard as HaskellDB's main strengths?

- What do you regard as HaskellDB's main weaknesses?

- How would you like to see HaskellDB improved on in the future?

- Any final comments you want to add?

/Anders