From: <bri...@cs...> - 2006-03-20 18:00:51
|
Marc Weber wrote: >>I once ran into a similar problem in ghci when I had an unneccessary=20 >>"-lc" in the package configuration, and my libc.so was a linker script.= =20 >=20 > Thanks a lot.. It's working like a charm now.. What did you do to solve the problem? It'd be nice to know in case it=20 happens to someone else. > I have some suggestions.. I don't know wether you've already thought > about this? >=20 > The example still use genericConnect (which seems to be dynConnnect > ,now)... Yeah, you're right, the documentation needs to be updated. It's just=20 that noone has taken the time to do it yet. > One thing I checked for (because I had this problem some years ago usin= g > different databases) is quoting that they use different quoting. It too= k > me some time to realize that this is not implemented (I've grepped the > whole source many times for ` and [. beeing used by MySQL and MS > Access. So by now it's not possible to use whitespaces in field names. >=20 > Databases have additional functions. Such as adding dates, random > numbers (what the hell there might be) String functions (might be done > in haskell.. What might be faster?).. Would be really unbeatable to > have some kind of abstraction here, too. Unfortunately I'm not familiar > enough with the code, yet. There is currently no support for additional features or idiosyncracies=20 of individual database systems. It has been talked about in the past,=20 but not implemented. As you mention, there are two different issues here: - Different handling of stuff that should be supported by the core=20 HaskellDB interface. e.g. quoting, limiting the number of query results,=20 etc. - Extra features supported by some system, e.g. extra built-in=20 functions, special types. I think that the former should be handled by some customized SQL=20 generation for each backend. This should be allowed to be independent of=20 the driver used, since with for example ODBC we can't know what system=20 we are talking to. The latter might be handled by having modules extending the basic=20 HaskellDB interface, adding the extra features. > I'm still trying to get everything to work. > Is this correct=20 > myquery=3Ddo -- << query works find > t<-Q.table TblLang.languages > return t >=20 > main=3Ddo > t <- connect $ \db -> query db myquery > (\r -> (putStrLn.show) r!TblLang.iD) (GHC.List.head t) -- << here man= y errors after trying to only get field TblLang.iD > mapM_ (putStrLn . show) t -- showing all works fine The problem seems to be with the middle line. I think that you are only=20 really missing a pair of parantheses around r!TblLang.iD. Note that=20 function application binds harder than the ! operator. I think this line=20 would be easier to read if you wrote it as: putStrLn $ show $ (head t)!TblLang.iD > errors: (copied from vim) > test2.hs|34| 26: > || No instance for (Select (Attr StoreDatabase.Languages.ID Int) > || (IO ()) > || (IO a)) > arising from use of `!' at test2.hs|34| 26 > || Probable fix: > || add an instance declaration for (Select (Attr StoreDatabase.La= nguages.ID > || Int) > || (IO ()) > || (IO a)) > || In a lambda abstraction: > || \ r -> ((putStrLn . show) r) ! StoreDatabase.Languages.iD > || In a 'do' expression: > || (\ r -> ((putStrLn . show) r) > || ! StoreDatabase.Languages.iD) (GHC.List.head t) > || In the definition of `main': > || main =3D do > || t <- connect $ (\ db -> query db myquery) > || (\ r -> ((putStrLn . show) r) > || ! StoreDatabase.Languages.iD) (GHC.List.head t) > || mapM_ (putStrLn . show) t >=20 > Does this mean I've forgotton to import a module? > i've tried adding all exposed modules (ghc-pkg describe haskelldb) > Same result. > Do you have again some hints? If it were a missing imports problem, you would probably get errors=20 about missing identifiers. The unreadable error message that you got looks that bad because we had=20 to invent our own record types. /Bj=F6rn |