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

Re: [Haskelldb-users] Fwd: Haskelldb problems: website and current Hackage release

[Justin B. <jgb...@gm...>]

I have a couple of items I will try and put together. One is a
postgres patch, the other some added functionality for reconstructing
columns from query types. If I don't get a patch in the next few days,
though, don't wait for me.

On Tue, Mar 18, 2008 at 10:52 AM, Bjorn Bringert <bj...@br...> wrote:
> On Sun, Mar 16, 2008 at 5:32 AM, Gwern Branwen <gw...@gm...> wrote:
>   > I think a new release of HaskellDB needs to be made. The current
>   >  version on Hackage is just too old:
>   >
>   >
>   >   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>   >  > gwern@localhost:1039~/hswebforms>cabal install haskelldb > > [
>   >  2:02AM] >
>   >   > 'haskelldb-0.10' is cached. >
>   >   > [1 of 1] Compiling Main             ( Setup.hs, dist/setup/Main.o ) >
>   >   > Linking dist/setup/setup ... >
>   >   > Configuring haskelldb-0.10... >
>   >   > Warning: No 'build-type' specified. If possible use
>  'build-type: Simple'. >
>   >   > Preprocessing library haskelldb-0.10... >
>   >   > Building haskelldb-0.10... >
>   >   > >
>   >   > src/Database/HaskellDB.hs:87:7: >
>   >   > Could not find module `Text.PrettyPrint.HughesPJ': >
>   >   > it is a member of package pretty-1.0.0.0, which is hidden >
>   >   > cabal: Error: some packages failed to install: >
>   >   > haskelldb-0.10 failed during the building phase. >
>   >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>   >
>   >   The latest release on Hackage is not even updated for the split-base
>   >  of GHC 6.8.x.
>   >
>   >   Since the Darcs repository worked fine, I think a sdist tarball needs
>   >  to be made and uploaded.
>
>   Yes, this is a good idea. Does anyone have anything ready to go in a
>   new release that they haven't pushed yet? Does the current darcs
>   version build and work ok enough for the current users?
>
>
>
>
>   >   Another issue is that <http://haskelldb.sourceforge.net/> says:
>   >
>   >   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>   >  > You can also try asking HaskellDB questions in the Haskell IRC
>   >  channel, > > #haskelldb at freenode.net.
>   >               >
>   >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>   >
>   >   #haskelldb was wholly unpopulated when I joined. So this line should
>   >  be removed.
>
>   Yes, thanks for pointing that out. I'll dig up my SourceForge
>   credentials and try to fix that.
>
>
>
>   I'm traveling at the moment, so I may take a while to respond to e-mail.
>
>   /Björn
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Haskelldb-users mailing list
>  Has...@li...
>  https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Fwd: Haskelldb problems: website and current Hackage release

[Bjorn B. <bj...@br...>]

On Sun, Mar 16, 2008 at 5:32 AM, Gwern Branwen <gw...@gm...> wrote:
 > I think a new release of HaskellDB needs to be made. The current
 >  version on Hackage is just too old:
 >
 >
 >   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 >  > gwern@localhost:1039~/hswebforms>cabal install haskelldb > > [
 >  2:02AM] >
 >   > 'haskelldb-0.10' is cached. >
 >   > [1 of 1] Compiling Main             ( Setup.hs, dist/setup/Main.o ) >
 >   > Linking dist/setup/setup ... >
 >   > Configuring haskelldb-0.10... >
 >   > Warning: No 'build-type' specified. If possible use
'build-type: Simple'. >
 >   > Preprocessing library haskelldb-0.10... >
 >   > Building haskelldb-0.10... >
 >   > >
 >   > src/Database/HaskellDB.hs:87:7: >
 >   > Could not find module `Text.PrettyPrint.HughesPJ': >
 >   > it is a member of package pretty-1.0.0.0, which is hidden >
 >   > cabal: Error: some packages failed to install: >
 >   > haskelldb-0.10 failed during the building phase. >
 >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 >
 >   The latest release on Hackage is not even updated for the split-base
 >  of GHC 6.8.x.
 >
 >   Since the Darcs repository worked fine, I think a sdist tarball needs
 >  to be made and uploaded.

 Yes, this is a good idea. Does anyone have anything ready to go in a
 new release that they haven't pushed yet? Does the current darcs
 version build and work ok enough for the current users?



 >   Another issue is that <http://haskelldb.sourceforge.net/> says:
 >
 >   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 >  > You can also try asking HaskellDB questions in the Haskell IRC
 >  channel, > > #haskelldb at freenode.net.
 >               >
 >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 >
 >   #haskelldb was wholly unpopulated when I joined. So this line should
 >  be removed.

 Yes, thanks for pointing that out. I'll dig up my SourceForge
 credentials and try to fix that.



 I'm traveling at the moment, so I may take a while to respond to e-mail.

 /Björn

[Haskelldb-users] Haskelldb problems: website and current Hackage release

[Gwern B. <gw...@gm...>]

I think a new release of HaskellDB needs to be made. The current
version on Hackage is just too old:


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> gwern@localhost:1039~/hswebforms>cabal install haskelldb > > [
2:02AM] >
 > 'haskelldb-0.10' is cached. >
 > [1 of 1] Compiling Main             ( Setup.hs, dist/setup/Main.o ) >
 > Linking dist/setup/setup ... >
 > Configuring haskelldb-0.10... >
 > Warning: No 'build-type' specified. If possible use 'build-type: Simple'. >
 > Preprocessing library haskelldb-0.10... >
 > Building haskelldb-0.10... >
 > >
 > src/Database/HaskellDB.hs:87:7: >
 > Could not find module `Text.PrettyPrint.HughesPJ': >
 > it is a member of package pretty-1.0.0.0, which is hidden >
 > cabal: Error: some packages failed to install: >
 > haskelldb-0.10 failed during the building phase. >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 The latest release on Hackage is not even updated for the split-base
of GHC 6.8.x.

 Since the Darcs repository worked fine, I think a sdist tarball needs
to be made and uploaded.

 -----

 Another issue is that <http://haskelldb.sourceforge.net/> says:

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> You can also try asking HaskellDB questions in the Haskell IRC
channel, > > #haskelldb at freenode.net.
              >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 #haskelldb was wholly unpopulated when I joined. So this line should
be removed.

 --
 gwern
 JOTS claymore MI5 DES .tm Dictionary Gripan Submarine Bach data-haven

[Haskelldb-users] Using template haskell to create pseudo columns

[Justin B. <jgb...@gm...>]

Adding pseudo columns to a projection is cumbersome, to say the list.
For example, to add a field named "hidden" to a query I have to write:

  data Hide = Hide
  instance FieldTag Hide where
    fieldName _ = "hide"

  hideField = mkAttr Hide

I wrote a little Template haskell that reduces this to:

  $(mkField "hide")

If you want to customize the name of the column in the generated SQL,
another function is used:

  $(mkFieldWithName "NumPullingParts" "num_pulling_parts")

The code is below. Some questions:

  * Does the code look reasonable and useful?
  * Would the haskelldb maintainers want to introduce a dependency on
template haskell to haskelldb for this kind of code?
  * Otherwise, would an "extensions" package make sense?

If the reaction is positive, I'll work on extending this for a patch.
My heartfelt thanks to Bulat for his excellent template haskell
tutorials. I really wish that library had better documentation!

Justin

mkField :: String -> Q [Dec]
mkField [] = error "Can't generate field from an empty string."
mkField f =
  let fieldType = if isUpper (head f) then f else (toUpper (head f)) : tail f
      colName = if isLower (head f) then f else (toLower (head f)) : tail f
  in mkFieldWithName fieldType colName

-- ^ Creates a compile time field declaration using the given
-- arguments for the type and column name of the field. The fieldType argument
-- is used to produce the "<field name>Field" function which can be used to
-- add the field to a projection.
--
-- Note that an error will occur if fieldType is not a proper
type/constructor name.
mkFieldWithName :: String -> String -> Q [Dec]
mkFieldWithName [] _ = error "Can't create a field with an empty type."
mkFieldWithName _ [] = error "Can't create a field with an empty column name."
mkFieldWithName fieldType colName =
  let ty = mkName fieldType
      fieldName = toLower (head fieldType) : tail fieldType
      fieldD = [DataD [] ty [] [NormalC ty []] []]
      fieldI = [InstanceD [] (AppT (ConT (mkName
"Database.HaskellDB.HDBRec.FieldTag"))
                                   (ConT ty)) [FunD (mkName
"fieldName") [Clause [WildP]
                                                      (NormalB (LitE
(StringL colName))) []]]]
      fieldF = [ValD (VarP (mkName (fieldName ++ "Field"))) (NormalB
(AppE (VarE (mkName "Database.HaskellDB.DBLayout.mkAttr"))
                                                              (ConE ty))) []]
  in return (fieldD ++ fieldI ++ fieldF)

Re: [Haskelldb-users] Default values

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

On Feb 3, 2008, at 17:52 , GrayShade wrote:

> (I'm sorry for starting another thread about this, but I couldn't
> manage to reply to the old message).
>
> Is there any way to use default values when inserting into a table?
>
> Laurentiu Nicola

Yes, use _default.

/Bj=F6rn

[Haskelldb-users] Default values

[GrayShade <gra...@gm...>]

(I'm sorry for starting another thread about this, but I couldn't
manage to reply to the old message).

Is there any way to use default values when inserting into a table?

Laurentiu Nicola

Re: [Haskelldb-users] Improving 'project'

[Alain C. <al...@po...>]

Björn Bringert a écrit :
> On Jan 30, 2008, at 19:01 , Justin Bailey wrote:
>
>> All,
>>
>> project doesn't easily let me add a few columns to an existing query
>> (or take a few columns away). Instead, each use of project requires me
>> to build the entire list of columns I'd like to pass on by hand.
>> Before I go further, if there is a way to do that, please let me know.
>
> No, there is no existing way to achieve this. Indeed, it's one of the 
> most common complaints about HaskellDB :-)
>
>
>>  3) If not 2, how can the solution above be better? I'd like to extend
>> it to adding/removing arbitrary columns and  more control over column
>> order.
>
> The best way to do it would be to add powerful record types to Haskell...
>
> You may want to look at HList, http://homepages.cwi.nl/~ralf/HList/ 
> <http://homepages.cwi.nl/%7Eralf/HList/> I'm not sure how much HList 
> can do now, perhaps they have added things since they wrote the paper. 
> There might be some nice record manipulation stuff there that you 
> could use. Porting HaskellDB to use HList instead of its own records 
> would be nice, if the HList code is in good shape. 
>
Hi,

The HList library compiles with ghc-6.8.2, and seems to be maintained. 
Indeed it would be a great idea to use it instead of HaskellDB's own 
heterogeneous list system.

Alain

Re: [Haskelldb-users] Improving 'project'

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

On Jan 30, 2008, at 19:01 , Justin Bailey wrote:

> All,
>
> project doesn't easily let me add a few columns to an existing query
> (or take a few columns away). Instead, each use of project requires me
> to build the entire list of columns I'd like to pass on by hand.
> Before I go further, if there is a way to do that, please let me know.

No, there is no existing way to achieve this. Indeed, it's one of the =20=

most common complaints about HaskellDB :-)

> An example of what I'd like to do is below. Imagine I want to add a
> "selected" boolean column to my query.
>
>   select_customers =3D do
>      cust <- table customers
>      project ( (selectedField <<- False) # cust)
>
> So I get all the columns in my customers table, plus the "selected"
> column. Unfortunately the code above doesn't work.
>
> cust has type "Rel r", and project wants a "Record r", so I originally
> tried something like:
>
>   select_customers =3D do
>     let toRec :: Rel r -> Record r
>          toRec _ =3D undefined
>     ...
>     project (unRel cust)
>
> But project needs to recover the "Expr" values associated with 'r' and
> this fails. I then came up with this solution, which lets me add
> columns at the head of a query:
>
>   class RecoverExpr a b where
>     toExpr :: a -> b
>
>   instance RecoverExpr RecNil RecNil where
>     toExpr rec =3D RecNil
>
>   instance (FieldTag f, RecoverExpr r r) =3D> RecoverExpr (RecCons f
> (Expr b) r) (RecCons f (Expr b) r) where
>     toExpr ~rec@(RecCons _ r) =3D RecCons (attribute . fieldName $
> recField $ rec) (toExpr r)
>
>   recField :: RecCons f a b -> f
>   recField _ =3D undefined
>
>   rest :: (RecoverExpr r r) =3D> Rel r -> r
>   rest qry =3D
>     let unRel :: Rel r -> r
>         unRel _ =3D undefined
>     in toExpr . unRel $ qry
>
> Then I can write:
>
>   select_customers  =3D do
>     cust <- table customers_tbl
>     ...
>     project (selectField <<- False # (rest cust))
>
> And it actually works. However, it seems over-engineered. My =20
> questions are:
>
>  1) Is there a way to make project behave like I want without these =20=

> tricks?

I doubt that there is. In general, manipulating record types with =20
Haskell's roundabout type level programming is messy, there's no =20
avoiding that.

>  2) If not 1, would it make more sense for the Query monad to pack
> around the original Expr values?

Hmm, wouldn't it need to carry those through arbitrary query =20
computations?

>  3) If not 2, how can the solution above be better? I'd like to extend
> it to adding/removing arbitrary columns and  more control over column
> order.

The best way to do it would be to add powerful record types to =20
Haskell...

You may want to look at HList, http://homepages.cwi.nl/~ralf/HList/ =20
I'm not sure how much HList can do now, perhaps they have added =20
things since they wrote the paper. There might be some nice record =20
manipulation stuff there that you could use. Porting HaskellDB to use =20=

HList instead of its own records would be nice, if the HList code is =20
in good shape.

> Thanks for any and all thoughts!
>
> Justin
>
> p.s. Sorry for the spam on cafe - I accidently sent this there =20
> first ...


/Bj=F6rn

[Haskelldb-users] Improving 'project'

[Justin B. <jgb...@gm...>]

All,

project doesn't easily let me add a few columns to an existing query
(or take a few columns away). Instead, each use of project requires me
to build the entire list of columns I'd like to pass on by hand.
Before I go further, if there is a way to do that, please let me know.

An example of what I'd like to do is below. Imagine I want to add a
"selected" boolean column to my query.

  select_customers = do
     cust <- table customers
     project ( (selectedField <<- False) # cust)

So I get all the columns in my customers table, plus the "selected"
column. Unfortunately the code above doesn't work.

cust has type "Rel r", and project wants a "Record r", so I originally
tried something like:

  select_customers = do
    let toRec :: Rel r -> Record r
         toRec _ = undefined
    ...
    project (unRel cust)

But project needs to recover the "Expr" values associated with 'r' and
this fails. I then came up with this solution, which lets me add
columns at the head of a query:

  class RecoverExpr a b where
    toExpr :: a -> b

  instance RecoverExpr RecNil RecNil where
    toExpr rec = RecNil

  instance (FieldTag f, RecoverExpr r r) => RecoverExpr (RecCons f
(Expr b) r) (RecCons f (Expr b) r) where
    toExpr ~rec@(RecCons _ r) = RecCons (attribute . fieldName $
recField $ rec) (toExpr r)

  recField :: RecCons f a b -> f
  recField _ = undefined

  rest :: (RecoverExpr r r) => Rel r -> r
  rest qry =
    let unRel :: Rel r -> r
        unRel _ = undefined
    in toExpr . unRel $ qry

Then I can write:

  select_customers  = do
    cust <- table customers_tbl
    ...
    project (selectField <<- False # (rest cust))

And it actually works. However, it seems over-engineered. My questions are:

 1) Is there a way to make project behave like I want without these tricks?
 2) If not 1, would it make more sense for the Query monad to pack
around the original Expr values?
 3) If not 2, how can the solution above be better? I'd like to extend
it to adding/removing arbitrary columns and  more control over column
order.

Thanks for any and all thoughts!

Justin

p.s. Sorry for the spam on cafe - I accidently sent this there first ...

Re: [Haskelldb-users] haskelldb basic documentation needed for connecton to MySQL

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

On Jan 27, 2008, at 01:35 , Immanuel Normann wrote:

> I posted this two weeks ago also to haskell-cafe, but the answers =20
> didn't help that much. So I try here again:
>
> with the release update haskelldb-0.9 -> haskelldb-0.10 several =20
> things have changed. Unfortunately the API documentation does not =20
> give enough information in generall. Is there any additional =20
> uptodate documentation around?
> In particular the fundamental function "connect" hast a new signature:
> connect :: (forall m a . MonadIO m =3D> [(String, String)] -> =20
> (Database -> m a) -> m a)
> I don't know what pairs of strings this function needs. The API =20
> description is to unspecific:
>
> The connect function takes some driver specific name, value pairs =20
> use to setup the database connection, and a database action to run.
>
> What are the specific name value pairs needed (for a connection to =20
> a mysql db )?
> I got the following hint:
> Your best bet is to download the appropriate drivers - either =20
> haskelld-hdbc-mysql or haskelldb-hsql-mysql. If you get the =20
> haskelldb sources via darcs, you can also look in the test =20
> directory to see how the connections are established.
>
> In my specific case, I am using PostgreSQL and by login  function =20
> looks like this:
>
> -- ^ Returns a function which can log into the database and perform =20=

> operations.
> login :: MonadIO m =3D> String -> Int -> String -> String -> String -=20=

> > (Database -> m a) -> m a
> login server port user password dbname =3D postgresqlConnect =20
> [("host", server),
>   ("port", show port),
>   ("user", user),
>   ("password", password),
>   ("dbname", dbname)]
>
> I don't understand how to map this to my problem. What in fact do I =20=

> have to install?
> For MySQL there seem to be the following dependencies when I try to =20=

> setup haskelldb-hsql-mysql-0.10 froma hackage:
> - haskelldb-hsql-0.10
> - hsql-1.7
> - hsql-mysql-1.7
> I haven't manage to install them with ghc-6.8.2 yet. Nevertheless I =20=

> wouldn't know how to use this "cpnnect" function. Moreover, in =20
> contrast to the haddock type description I observe with ghci and :t =20=

> connect the following type:
> connect :: (MonadIO m) =3D>
>            DriverInterface
>            -> [(String, String)]
>            -> (Database.HaskellDB.Database.Database -> m a)
>            -> m a
> I don't what to take for "DriverInterface"? The API docu says:
> "Default dummy driver, real drivers should overload this"
> How should this be done concretely for MySQL?
>
> Some more detailed docu would be helpful.

Hi Immanuel,

Sorry about the poor state of the HaskellDB documentation.

Short story:

1. Install the darcs versions of these packages:

hsql
hsql-mysql
haskelldb
haskelldb-hsql
haskelldb-hsql-mysql

2. Import Database.HaskellDB.HSQL.MySQL

3. You need these options:

options =3D
  [("server","<server host name>"),
   ("db","<database name>"),
   ("uid","<username>"),
  ("pwd","<password>")]

4. Call:

connect driver options <your function>


You currently need the darcs versions since HSQL 1.7 does not compile =20=

under GHC 6.8.2.

There really ought to be an up-to-date HaskellDB tutorial. Perhaps it =20=

should live on the Haskell Wiki so that everyone can contribute.

/Bj=F6rn

[Haskelldb-users] haskelldb basic documentation needed for connecton to MySQL

[Immanuel N. <imm...@go...>]

I posted this two weeks ago also to haskell-cafe, but the answers didn't
help that much. So I try here again:

with the release update haskelldb-0.9 -> haskelldb-0.10 several things have
changed. Unfortunately the API documentation does not give enough
information in generall. Is there any additional uptodate documentation
around?
In particular the fundamental function "connect" hast a new signature:
*connect* :: (forall m a .
MonadIO<http://hackage.haskell.org/packages/archive/mtl/1.1.0.0/doc/html/Control-Monad-Trans.html#t%3AMonadIO>m
=> [(
String<http://hackage.haskell.org/packages/archive/base/3.0.0.0/doc/html/Data-Char.html#t%3AString>,
String<http://hackage.haskell.org/packages/archive/base/3.0.0.0/doc/html/Data-Char.html#t%3AString>)]
-> (Database -> m a) -> m a)
I don't know what pairs of strings this function needs. The API description
is to unspecific:

The connect function takes some driver specific name, value pairs use to
> setup the database connection, and a database action to run.


What are the specific name value pairs needed (for a connection to a mysql
db )?
I got the following hint:

> Your best bet is to download the appropriate drivers - either
> haskelld-hdbc-mysql or haskelldb-hsql-mysql. If you get the haskelldb
> sources via darcs, you can also look in the test directory to see how the
> connections are established.
>
> In my specific case, I am using PostgreSQL and by login  function looks
> like this:
>
> -- ^ Returns a function which can log into the database and perform
> operations.
> login :: MonadIO m => String -> Int -> String -> String -> String ->
> (Database -> m a) -> m a
> login server port user password dbname = postgresqlConnect [("host",
> server),
>   ("port", show port),
>   ("user", user),
>   ("password", password),
>   ("dbname", dbname)]


I don't understand how to map this to my problem. What in fact do I have to
install?
For MySQL there seem to be the following dependencies when I try to setup
haskelldb-hsql-mysql-0.10 froma hackage:
- haskelldb-hsql-0.10
- hsql-1.7
- hsql-mysql-1.7
I haven't manage to install them with ghc-6.8.2 yet. Nevertheless I wouldn't
know how to use this "cpnnect" function. Moreover, in contrast to the
haddock type description I observe with ghci and :t connect the following
type:
connect :: (MonadIO m) =>
           DriverInterface
           -> [(String, String)]
           -> (Database.HaskellDB.Database.Database -> m a)
           -> m a
I don't what to take for "DriverInterface"? The API docu says:
"Default dummy driver, real drivers should overload this"
How should this be done concretely for MySQL?

Some more detailed docu would be helpful.

Thanks,
Immanuel

Re: [Haskelldb-users] Converting type information from a query into values

[Justin B. <jgb...@gm...>]

On Jan 24, 2008 12:29 PM, Bjorn Bringert <bri...@cs...> wrote:
> This looks good to me.

Excellent, I'll polish it and submit. If you have any naming
suggestions, don't hesitate to send them.

>
> I don't quite see why it would be necessary to add ExprTypes
> constraints to the existing functions, since they don't use the
> fieldTypes function. What is it that you want to be able to do?

I'm still getting used to typeclasses and I see what you are saying. I
thought that, in order to use fieldTypes on a given Query, I'd need to
ensure all types used by that query had the ExprTypes constraint. Just
a misunderstanding on my part.

Justin

Re: [Haskelldb-users] Converting type information from a query into values

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

On Jan 24, 2008, at 19:48 , Justin Bailey wrote:

> All,
>
> After building a query, it usually has a type such as:
>
>   Query (Rel (RecCons SomeField (Expr SomeType) (RecCons AnotherField
> (Expr AnotherType) (... RecNil) ... )
>
> I would like to recover the type of each column, much like you can
> recover the name of each field.  I didn't see an existing way to do
> this, but there is a FieldType value and a FieldDesc alias defined in
> FieldType.hs which looked promising. FieldType represents the Haskell
> type associated with a field (Int, Bool, etc.), while FieldDesc is
> just a tuple holding a FieldType and a Bool indicating if the field is
> nullable.
>
> I came up with this typeclass to recover column type information:
>
> -- | Class which retrieves a field description from a given type.
> class ExprType e where
>   fieldType :: e -> FieldDesc
>
> -- | Class which returns a list of field descriptions. Used with
> -- Record types.
> class ExprTypes r where
>   fieldTypes :: r -> [FieldDesc]
>
> Some of the more interesting instances of ExprType:
>
>   -- If an expression represents a type which can be recovered, we  
> can recover
>   -- the type of the entire expression
>   instance (ExprType a) => ExprType (Expr a) where
>     ...
>
>   -- A Maybe type is nullable, so set the second item in the tuple  
> to True.
>   instance (ExprType a) => ExprType (Maybe a) where
>     fieldType ~(Just e) = ((fst . fieldType $ e), True)
>
>   -- We can recover the length of a bounded string and create an
> appropriate BStrT value
>   instance (Size n) => ExprType (BoundedString n) where
>     fieldType b = (BStrT (listBound b), False)
>
> I defined ExprTypes instances on Records much like the ShowLabels
> instances are defined in HDBRec.hs:
>
>   instance ExprTypes RecNil where
>     fieldTypes _ = []
>
>   instance (ExprType e, ExprTypes r) => ExprTypes (RecCons f e r)  
> where
>     fieldTypes ~f@(RecCons e r) =
>       let getFieldType :: RecCons f a r -> a
>           getFieldType = undefined
>       in (fieldType . getFieldType $ f) : fieldTypes r
>
>   instance ExprTypes r => ExprTypes (Record r) where
>     fieldTypes r = fieldTypes (r RecNil)
>
> Does this seem patch worthy? To recover type information from any
> Query type would require that the ExprTypes context be added to
> existing functions. I think it would have to be added everywhere the
> ShowLabels context is found. Would it make sense to add this context
> to the other types of DB operations (update/delete/insert)?

This looks good to me.

I don't quite see why it would be necessary to add ExprTypes  
constraints to the existing functions, since they don't use the  
fieldTypes function. What is it that you want to be able to do?

/Bjorn

Re: [Haskelldb-users] Recoving RecCons structure from Query (Rel ...)

[Justin B. <jgb...@gm...>]

On Jan 22, 2008 8:35 AM, Bj=F6rn Bringert <bri...@cs...> wrote:
>
> I think that this is reasonable. Any place that does pattern matching
> just to recover the types of some constructor arguments should use lazy
> pattern matching (aka irrefutable patterns). Consider the current code
> buggy.

Attached you'll find a patch that adds lazy patterns in HDBRec.hs and Query=
.hs.

Justin

[Haskelldb-users] Converting type information from a query into values

[Justin B. <jgb...@gm...>]

All,

After building a query, it usually has a type such as:

  Query (Rel (RecCons SomeField (Expr SomeType) (RecCons AnotherField
(Expr AnotherType) (... RecNil) ... )

I would like to recover the type of each column, much like you can
recover the name of each field.  I didn't see an existing way to do
this, but there is a FieldType value and a FieldDesc alias defined in
FieldType.hs which looked promising. FieldType represents the Haskell
type associated with a field (Int, Bool, etc.), while FieldDesc is
just a tuple holding a FieldType and a Bool indicating if the field is
nullable.

I came up with this typeclass to recover column type information:

-- | Class which retrieves a field description from a given type.
class ExprType e where
  fieldType :: e -> FieldDesc

-- | Class which returns a list of field descriptions. Used with
-- Record types.
class ExprTypes r where
  fieldTypes :: r -> [FieldDesc]

Some of the more interesting instances of ExprType:

  -- If an expression represents a type which can be recovered, we can recover
  -- the type of the entire expression
  instance (ExprType a) => ExprType (Expr a) where
    ...

  -- A Maybe type is nullable, so set the second item in the tuple to True.
  instance (ExprType a) => ExprType (Maybe a) where
    fieldType ~(Just e) = ((fst . fieldType $ e), True)

  -- We can recover the length of a bounded string and create an
appropriate BStrT value
  instance (Size n) => ExprType (BoundedString n) where
    fieldType b = (BStrT (listBound b), False)

I defined ExprTypes instances on Records much like the ShowLabels
instances are defined in HDBRec.hs:

  instance ExprTypes RecNil where
    fieldTypes _ = []

  instance (ExprType e, ExprTypes r) => ExprTypes (RecCons f e r) where
    fieldTypes ~f@(RecCons e r) =
      let getFieldType :: RecCons f a r -> a
          getFieldType = undefined
      in (fieldType . getFieldType $ f) : fieldTypes r

  instance ExprTypes r => ExprTypes (Record r) where
    fieldTypes r = fieldTypes (r RecNil)

Does this seem patch worthy? To recover type information from any
Query type would require that the ExprTypes context be added to
existing functions. I think it would have to be added everywhere the
ShowLabels context is found. Would it make sense to add this context
to the other types of DB operations (update/delete/insert)?

Justin

Re: [Haskelldb-users] Recoving RecCons structure from Query (Rel ...)

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

Justin Bailey wrote:
> I have a value which is a query, Query (Rel r). I would like to
> recover the columns and types used in the query. The ShowLabel
> instance looks like the way to go, but I was not sure how to recover
> the ReCons/RecNil value structure necessary. My first attempt is
> below. "def" is defined as "Query (Rel r)":
> 
>   unRel :: (Rel r) -> r
>   unRel r = undefined
> 
>   tableColumns :: ModelTable -> [String]
>   tableColumns (ModelTable _ _ _ def _) = recordLabels . unRel . snd .
> runQueryRel $ def
> 
> The types work out but the undefined in unRel causes a runtime error.
> Looking at the instances for ShowLabels, I found the culprit:
> 
>   instance (FieldTag f,ShowLabels r) => ShowLabels (RecCons f a r) where
>       recordLabels x@(RecCons _ r) = consFieldName x : recordLabels r
> 
> Even though consFieldName never looks at its argument, the pattern
> match causes the failure. I modified the ShowLabels instance so it
> makes a lazy pattern match:
> 
> instance (FieldTag f,ShowLabels r) => ShowLabels (RecCons f a r) where
>     recordLabels ~x@(RecCons _ r) = consFieldName x : recordLabels r
> 
> And lo and behold, it works! Now - is that advisable? Can anyone see a
> problem with other portions of the system? There are several other
> instances in HDBRec.hs where it looks like lazy matches should be
> made. What's nice is, if the RecCons values really are needed, they
> are still available to those that supplied them.
> 
> I'll submit a patch if it seems like a reasonable change.

I think that this is reasonable. Any place that does pattern matching 
just to recover the types of some constructor arguments should use lazy 
pattern matching (aka irrefutable patterns). Consider the current code 
buggy.

/Björn

[Haskelldb-users] Recoving RecCons structure from Query (Rel ...)

[Justin B. <jgb...@gm...>]

I have a value which is a query, Query (Rel r). I would like to
recover the columns and types used in the query. The ShowLabel
instance looks like the way to go, but I was not sure how to recover
the ReCons/RecNil value structure necessary. My first attempt is
below. "def" is defined as "Query (Rel r)":

  unRel :: (Rel r) -> r
  unRel r = undefined

  tableColumns :: ModelTable -> [String]
  tableColumns (ModelTable _ _ _ def _) = recordLabels . unRel . snd .
runQueryRel $ def

The types work out but the undefined in unRel causes a runtime error.
Looking at the instances for ShowLabels, I found the culprit:

  instance (FieldTag f,ShowLabels r) => ShowLabels (RecCons f a r) where
      recordLabels x@(RecCons _ r) = consFieldName x : recordLabels r

Even though consFieldName never looks at its argument, the pattern
match causes the failure. I modified the ShowLabels instance so it
makes a lazy pattern match:

instance (FieldTag f,ShowLabels r) => ShowLabels (RecCons f a r) where
    recordLabels ~x@(RecCons _ r) = consFieldName x : recordLabels r

And lo and behold, it works! Now - is that advisable? Can anyone see a
problem with other portions of the system? There are several other
instances in HDBRec.hs where it looks like lazy matches should be
made. What's nice is, if the RecCons values really are needed, they
are still available to those that supplied them.

I'll submit a patch if it seems like a reasonable change.

Justin

[Haskelldb-users] Small patch to DBDirect

[Justin B. <jgb...@gm...>]

All,

The attached patch updates DBDirect and adds some nice features:

  * The -fcontext-stack flag now works with OPTIONS_GHC at the top, so
I re-enabled it.
  * The type for tables generated (e.g. type TblOne = Table (RecCons
... )) made it hard to reuse the type in other contexts (e.g., your
own type signatures on queries). I removed the "Table" portion from
the type and added it to the table declaration function. An example is
probably best:

    type Options_tbl = (RecCons Pk (Expr Int) (RecCons ... RecNil) ... )

    options_tbl :: Table Options_tbl
    options = baseTable ...

Let me know how the patch looks. I can provide more motiviation for
the Table change if needed.

Justin

Re: [Haskelldb-users] Attempt at defining typeful primary key/foreign key relationships

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

On Dec 31, 2007, at 21:25 , Justin Bailey wrote:

Hi Justin,

> All,
>
> As part of my data model, I'd like to say there is a primary
> key/foreign key relationship between two tables/queries. Right now I
> only want to do this to capture some extra-query information that I'm
> using for code generation - I don't intend it to actually affect
> queries generated, though I'd like to go there eventually.
>
> I define a class which says there is a relation:
>
>  class HasRelation pk fk
>
> I define a type which holds relation values:
>
>   data Relation a pk fk p c =3D Relation { ... }
>
> Relation values can only be constructed by a function with appropriate
> constraints on it:
>
>   relation :: (HasRelation pk fk, HasField pk parent, HasField fk
> child) =3D> Attr pk a -> Attr fk a -> Rel parent -> Rel child ->
> Relation a pk fk parent child
>   relation primaryKey foreignKey prnt chld =3D Relation ....
>
> As an example, if I have tables Orders and LineItems, both with field
> order_id, I can establish a relationship by first defining an
> instance:
>
>   instance HasRelation Orders.Order_id LineItems.Order_id
>
> I can then create a relation value between the two:
>
>   orders <- table Orders.orders
>   lineItems <- table LineItems.lineItems
>   let r1 =3D relation Orders.order_id LineItems.order_id orders =20
> lineitems
>
> Note these types would be defined using DBDirect, so Order_id as a
> type with one constructor, lineItems has type "Table ...", etc. If I
> try to define an incorrect relation (wrong fields, fields in the wrong
> order, etc), then the above will not compile, which is just what I
> want.
>
> If you've read this far, I've not done any type-level programming or
> even played much with classes and instances before so I'd like to know
> if the approach makes sense. I took most of my inspiration from the
> HasField class in the HDBRec module.
>
>   1) Could this be simpler?  Any obvious deficiencies?

What's the purpose of the HasRelation class? Wouldn't just the =20
Relation type be enough?

>   2) I had to enable a number of extensions (though all of these are
> also enabled by haskelldb) - FlexibleInstances, FlexibleContexts,
> UndecidableInstances and OverlappingInstances. Should I be worried?

HaskellDB already uses most or all of those, so there's no need to =20
worry.

>   3) It's possible to define relationships among any two types. How
> can I limit that to 1) attributes with 2) the same type? Would I have
> to define an Attr typeclass, parallel to the Attr type?

Getting rid of HasRelation should solve this, AFAICT. But I haven't =20
thought this through in detail.


You may also want to have a look at the CoddFish paper: http://=20
wiki.di.uminho.pt/twiki/bin/view/Research/PURe/CoddFish
They do type-level programming to capture things like this.

/Bj=F6rn

[Haskelldb-users] Fwd: Attempt at defining typeful primary key/foreign key relationships

[Justin B. <jgb...@gm...>]

Small correction - the extensions listed at the bottom weren't
necessary. I had attempted to define a relationship among tables
automatically as:

  instance (HasField fk child, HasField pk parent, HasRelation pk fk)
=> HasRelation parent child

But that was redundant with the signature on relation. Removing it
allowed me to remove all extensions except MultiParameterTypeClasses.

Justin


---------- Forwarded message ----------
From: Justin Bailey <jgb...@gm...>
Date: Dec 31, 2007 12:25 PM
Subject: Attempt at defining typeful primary key/foreign key relationships
To: has...@li...


All,

As part of my data model, I'd like to say there is a primary
key/foreign key relationship between two tables/queries. Right now I
only want to do this to capture some extra-query information that I'm
using for code generation - I don't intend it to actually affect
queries generated, though I'd like to go there eventually.

I define a class which says there is a relation:

 class HasRelation pk fk

I define a type which holds relation values:

  data Relation a pk fk p c = Relation { ... }

Relation values can only be constructed by a function with appropriate
constraints on it:

  relation :: (HasRelation pk fk, HasField pk parent, HasField fk
child) => Attr pk a -> Attr fk a -> Rel parent -> Rel child ->
Relation a pk fk parent child
  relation primaryKey foreignKey prnt chld = Relation ....

As an example, if I have tables Orders and LineItems, both with field
order_id, I can establish a relationship by first defining an
instance:

  instance HasRelation Orders.Order_id LineItems.Order_id

I can then create a relation value between the two:

  orders <- table Orders.orders
  lineItems <- table LineItems.lineItems
  let r1 = relation Orders.order_id LineItems.order_id orders lineitems

Note these types would be defined using DBDirect, so Order_id as a
type with one constructor, lineItems has type "Table ...", etc. If I
try to define an incorrect relation (wrong fields, fields in the wrong
order, etc), then the above will not compile, which is just what I
want.

If you've read this far, I've not done any type-level programming or
even played much with classes and instances before so I'd like to know
if the approach makes sense. I took most of my inspiration from the
HasField class in the HDBRec module.

  1) Could this be simpler?  Any obvious deficiencies?
  2) I had to enable a number of extensions (though all of these are
also enabled by haskelldb) - FlexibleInstances, FlexibleContexts,
UndecidableInstances and OverlappingInstances. Should I be worried?
  3) It's possible to define relationships among any two types. How
can I limit that to 1) attributes with 2) the same type? Would I have
to define an Attr typeclass, parallel to the Attr type?

Thanks for any and all feedback. Happy New Year!

Justin

[Haskelldb-users] Attempt at defining typeful primary key/foreign key relationships

[Justin B. <jgb...@gm...>]

All,

As part of my data model, I'd like to say there is a primary
key/foreign key relationship between two tables/queries. Right now I
only want to do this to capture some extra-query information that I'm
using for code generation - I don't intend it to actually affect
queries generated, though I'd like to go there eventually.

I define a class which says there is a relation:

 class HasRelation pk fk

I define a type which holds relation values:

  data Relation a pk fk p c = Relation { ... }

Relation values can only be constructed by a function with appropriate
constraints on it:

  relation :: (HasRelation pk fk, HasField pk parent, HasField fk
child) => Attr pk a -> Attr fk a -> Rel parent -> Rel child ->
Relation a pk fk parent child
  relation primaryKey foreignKey prnt chld = Relation ....

As an example, if I have tables Orders and LineItems, both with field
order_id, I can establish a relationship by first defining an
instance:

  instance HasRelation Orders.Order_id LineItems.Order_id

I can then create a relation value between the two:

  orders <- table Orders.orders
  lineItems <- table LineItems.lineItems
  let r1 = relation Orders.order_id LineItems.order_id orders lineitems

Note these types would be defined using DBDirect, so Order_id as a
type with one constructor, lineItems has type "Table ...", etc. If I
try to define an incorrect relation (wrong fields, fields in the wrong
order, etc), then the above will not compile, which is just what I
want.

If you've read this far, I've not done any type-level programming or
even played much with classes and instances before so I'd like to know
if the approach makes sense. I took most of my inspiration from the
HasField class in the HDBRec module.

  1) Could this be simpler?  Any obvious deficiencies?
  2) I had to enable a number of extensions (though all of these are
also enabled by haskelldb) - FlexibleInstances, FlexibleContexts,
UndecidableInstances and OverlappingInstances. Should I be worried?
  3) It's possible to define relationships among any two types. How
can I limit that to 1) attributes with 2) the same type? Would I have
to define an Attr typeclass, parallel to the Attr type?

Thanks for any and all feedback. Happy New Year!

Justin

Re: [Haskelldb-users] Request for code review: Patch removing "distinct" option, adds "unique" function

[Peter G. <pe...@gm...>]

On 28/12/2007, at 12:42 AM, Bjorn Bringert wrote:

> I've just pushed a bunch of patches that add one DBDirect executable  
> for each driver.

OK, I'll try out haskelldb-hsql-postgresql.

BTW the latest Cabal-think is that you should not put optimisation  
options in Ghc-options. There are Cabal-level flags for that.

cheers
peter

Re: [Haskelldb-users] Request for code review: Patch removing "distinct" option, adds "unique" function

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

On Dec 21, 2007, at 18:32 , Peter Gammie wrote:

> On 21/12/2007, at 11:52 PM, Bjorn Bringert wrote:
>
>> On Dec 21, 2007, at 17:43 , Justin Bailey wrote:
>>> Things I'd like to do still:
>>>
>>> * Representation of foreign-key relationships (ideally extracted
>>> from the DB)
>>
>> I believe Peter Gammie has some code for foreign key constrains.
>> Peter: is that ready to be pulled into HaskellDB?
>
> I can email you (=3D=3D anyone who's interested) a patch that begins =
down
> that road. Roughly, I added support for defaults, foreign keys and
> primary keys. IIRC one can create tables with those things but the
> reflection is a bit weak, and the data description types are not
> fantastically robust. (The fieldnames are merely strings, e.g.)
>
> I haven't touched it for a few months now, as I decided it was less
> hassle to just use an SQL script.
>
> You will also need to renovate whatever DB backends you care about.
> (All Haskell DB bindings I looked at act as SQL bridges and treat
> tables merely as tuples.) I added some stuff to HSQL/PostgreSQL, and
> can email you those patches too, if you like. (I could port those to
> another <DB backend>/PostgreSQL if you can convince me there is some
> advantage in doing so - HSQL seemed to be simple, stable, etc. when I
> was looking into these things.)
>
> BTW what state is DBDirect in? I cannot compile hs-plugins (using GHC
> 6.6.1) presently, and I don't know what the future holds for that.
> ...


I've just pushed a bunch of patches that add one DBDirect executable =20
for each driver.

/Bj=F6rn

Re: [Haskelldb-users] Request for code review: Patch removing "distinct" option, adds "unique" function

[Peter G. <pe...@gm...>]

On 27/12/2007, at 1:19 AM, Justin Bailey wrote:

> On Dec 21, 2007 9:32 AM, Peter Gammie <pe...@gm...> wrote:
>> I can email you (== anyone who's interested) a patch that begins down
>> that road. Roughly, I added support for defaults, foreign keys and
>> primary keys. IIRC one can create tables with those things but the
>> reflection is a bit weak, and the data description types are not
>> fantastically robust. (The fieldnames are merely strings, e.g.)
>
> Sounds interesting, though I'm probably more interested in the
> reflection/representation side. Were those relationships able to be
> used in queries? In any case I wouldn't mind seeing the code.

I've attached two patches.

One is for this constraint stuff. It's for describing tables only, not  
for use in queries. (What do you have in mind? The possibility of  
doing natural joins?) It probably depends on some changes to the HSQL/ 
PostgreSQL driver that should be fairly obvious. I can send that patch  
along too if you want it. Note that the other backends do not conform  
to my changes to the types.

There is probably a lot of GHC warning elimination in that patch too.

The other fixes the expression generator - it does not generate enough  
parentheses for boolean expressions (at least). Bjorn, please adjust  
to taste and commit.

cheers
peter

Re: [Haskelldb-users] Request for code review: Patch removing "distinct" option, adds "unique" function

[Justin B. <jgb...@gm...>]

On Dec 21, 2007 9:32 AM, Peter Gammie <pe...@gm...> wrote:
> I can email you (== anyone who's interested) a patch that begins down
> that road. Roughly, I added support for defaults, foreign keys and
> primary keys. IIRC one can create tables with those things but the
> reflection is a bit weak, and the data description types are not
> fantastically robust. (The fieldnames are merely strings, e.g.)

Sounds interesting, though I'm probably more interested in the
reflection/representation side. Were those relationships able to be
used in queries? In any case I wouldn't mind seeing the code.

Justin