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

Re: [Haskelldb-users] uppercase Tablenames

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

> Hi
>
> I tried the tutorial on the haskell wiki [1] and used dbInfoToModuleFil=
es
> to create the DB Layout. As described I named the Table 'MyTable' but i=
n
> the created file DBInfo.hs, the table was named 'myTable' (caused by a
> call to 'checkLower' in DBSpecToDBDirect.hs). Obviously this did not wo=
rk
> with the Table that I created beforehand (with dbSpecToDatabase with th=
e
> original dbInfo as parameter).
>
> Is this behaviour on purpose? This would mean one could only use Table
> names that begin with lower case letters.
>
> As checkLower is also applied to Field names in DBSpecToDBDirect.hs I
> assume the same behaviour happens with Fields.
>
> [1] http://www.haskell.org/hawiki/HaskellDbTutorial

Hmm, I can't see any reason why the first letter of the table and field
names have to be lower case. Of course the Haskell identifiers for the
tables and fields have to, but not the strings with the actual field
names.

I have removed these calls to checkLower in CVS for now, can anyone shed
any light on why they were there in the first place? Chucky: maybe you
remember?

/Bj=F6rn

[Haskelldb-users] uppercase Tablenames

[<co...@da...>]

Hi

I tried the tutorial on the haskell wiki [1] and used dbInfoToModuleFiles
to create the DB Layout. As described I named the Table 'MyTable' but in
the created file DBInfo.hs, the table was named 'myTable' (caused by a
call to 'checkLower' in DBSpecToDBDirect.hs). Obviously this did not work
with the Table that I created beforehand (with dbSpecToDatabase with the
original dbInfo as parameter).

Is this behaviour on purpose? This would mean one could only use Table 
names that begin with lower case letters.

As checkLower is also applied to Field names in DBSpecToDBDirect.hs I 
assume the same behaviour happens with Fields.

[1] http://www.haskell.org/hawiki/HaskellDbTutorial

regards

Stefan

Re: [Haskelldb-users] DBDirect and GHC 6.4

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

Robert van Herk wrote:
> Hello all,
>=20
> I am still testing the cabalized version of HaskellDB. I see that=20
> DirectDB does not get built. Also, GenericConnect doesn't get built,=20
> which is somethuing that DirectDB uses.
>=20
> Is there a way to build directDB?

Hmm, yeah, that's a good question. I have now added some basic support=20
for HSQL 1.6 to the make-based build system, so that you should be able=20
to build DBDirect using make. After building and installing with Cabal,=20
just run ./configure and make, and you should have DBDirect as=20
build/ghc/DBDirect.

This is of course not ideal, but until the hs-plugins backend gets=20
fixed, this was the best I could come up with.

/Bj=F6rn

[Haskelldb-users] DBDirect and GHC 6.4

[Robert v. H. <rh...@cs...>]

Hello all,

I am still testing the cabalized version of HaskellDB. I see that 
DirectDB does not get built. Also, GenericConnect doesn't get built, 
which is somethuing that DirectDB uses.

Is there a way to build directDB?

Regards,
Robert

Re: [Haskelldb-users] GenericConnect ??

[Krasimir A. <ka2...@ya...>]

--- Bjorn Bringert <bri...@cs...> wrote:
> All in all, GenericConnect does not seem like a very
> good idea to me. I 
> think that the hs-plugins-based generic backend is a
> better idea. The 
> only problem is that I haven't yet had time to
> figure out how to make it 
> load drivers from the installed packages. Currently
> it expects an object 
> file in the current directory. Help here would be
> appreciated.

I would like to have dynamically loaded drivers in
HSQL but I don't like to use something like
hs-plugins. The problem with it is that you have to
load at runtime a copy of all packages which are
required from the dynamically loaded objects. In our
case this is the base package. We already have one
copy of base package which is already linked with the
program and you have to load a second copy just in
order to link the drivers. This has a significant
drawbacks to me. First of all this is a waste of space
and the second is that it might not work properly with
the static variables in base. I am sure that soon or
later we will have proper support for .dll under
Windows as well as we already have .dynlib under
MacOS. It will improve the things and then I will add
dynamic drivers.

Cheers,
  Krasimir



	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: [Haskelldb-users] GenericConnect ??

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

Robert van Herk wrote:
>>> I wonder why GenericConnect.pphs does not seem to get installed with=20
>>> the cabal package... Was this intended?
>>
>> Yes it was. The problem with GenericsConnect is that it imports all=20
>> the drivers that were compiled with it. This has a number of=20
>> problems:  ...
>=20
> Ah I see. Does this mean that currently, there is no way to connect to =
a=20
> database from GHC 6.4? I've been browsing the HaskellDB's test files,=20
> but they all seem to use GenericConnect...

The recommended way at the moment is to use one of the driver-specific=20
connection functions:

Database.HaskellDB.HSQL.MySQL.mysqlConnect
Database.HaskellDB.HSQL.ODBC.odbcConnect
Database.HaskellDB.HSQL.PostgreSQL.postgresqlConnect
Database.HaskellDB.HSQL.SQLite.sqliteConnect
Database.HaskellDB.WX.wxConnect

/Bj=F6rn

Re: [Haskelldb-users] GenericConnect ??

[Robert v. H. <rh...@cs...>]

>> I wonder why GenericConnect.pphs does not seem to get installed with 
>> the cabal package... Was this intended?
> Yes it was. The problem with GenericsConnect is that it imports all 
> the drivers that were compiled with it. This has a number of 
> problems:  ...
Ah I see. Does this mean that currently, there is no way to connect to a 
database from GHC 6.4? I've been browsing the HaskellDB's test files, 
but they all seem to use GenericConnect...

Regards,
Robert

Re: [Haskelldb-users] GenericConnect ??

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

Robert van Herk wrote:
> I'm currently testing the cabalized version of HaskellDB.
>=20
> I wonder why GenericConnect.pphs does not seem to get installed with th=
e=20
> cabal package... Was this intended?

Yes it was. The problem with GenericsConnect is that it imports all the=20
drivers that were compiled with it. This has a number of problems:

1) Any program using GenericConnect links with all the drivers that were=20
compiled along with GenericConnect, which makes the program large and=20
gives it a lot of link-time and run-time dependencies.

2) The package which would contain GenericConnect would have to depend=20
on all the driver packages, which means that that package cannot easily=20
be distributed, for example, as a binary RPM since the dependencies=20
would not be fixed.

All in all, GenericConnect does not seem like a very good idea to me. I=20
think that the hs-plugins-based generic backend is a better idea. The=20
only problem is that I haven't yet had time to figure out how to make it=20
load drivers from the installed packages. Currently it expects an object=20
file in the current directory. Help here would be appreciated.

/Bj=F6rn

[Haskelldb-users] GenericConnect ??

[Robert v. H. <rh...@cs...>]

Hi all,

I'm currently testing the cabalized version of HaskellDB.

I wonder why GenericConnect.pphs does not seem to get installed with the 
cabal package... Was this intended?

Regards,
Robert

[Haskelldb-users] HaskellDB and GHC 6.4/Cabal - finally works

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

I have just committed separate Cabal files for all the HaskellDB backend=20
drivers, using the same idea as Krasimir used in HSQL. The main cabal=20
file is haskelldb.cabal in the main directory, and in the driver-*=20
directories, there are Cabal files for each driver. All of them compile,=20
but I haven't tested any code with them.

So hopefully HaskellDB should now work fine with GHC 6.4 and Cabal.=20
Please report any problems.

/Bj=F6rn

[Haskelldb-users] Re: Haskelldb and GHC 6.4

[Robert v. H. <rh...@cs...>]

Dear Bj=F6rn, =20

Thanks for your reply. I'm looking forward to a working version of Haskel=
lDB, cause then I will be able to finish my thesis project :-)

By the way, when I try to compile from CVS, I get:

./build/ghc/libHShdb.a(MySQL.o)(.text+0x135): undefined reference to `Dat=
abaseziHSQLziMySQL_connect_closure'
./build/ghc/libHShdb.a(MySQL.o)(.text+0x4df): In function `__stginit_Data=
baseziHaskellDBziHSQLziMySQL_':
ghc9558.hc: undefined reference to `__stginit_DatabaseziHSQLziMySQL_'
./build/ghc/libHShdb.a(MySQL.o)(.rodata+0x40): undefined reference to `Da=
tabaseziHSQLziMySQL_connect_closure'
./build/ghc/libHShdb.a(MySQL.o)(.rodata+0x48): undefined reference to `Da=
tabaseziHSQLziMySQL_connect_closure'
./build/ghc/libHShdb.a(MySQL.o)(.rodata+0x54): undefined reference to `Da=
tabaseziHSQLziMySQL_connect_closure'
collect2: ld returned 1 exit status
make[1]: *** [build/ghc/DBDirect] Error 1
make[1]: Leaving directory `/home/robert/soft/src/haskell/build/haskelldb=
'
make: *** [all-ghc] Error 2

But maybe I am doing something wrong...

Regards,
Robert

Re: [Haskelldb-users] Haskelldb and GHC 6.4

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

Robert van Herk wrote:
> I am wondering: is there any kind of time frame yet on when HaskellDB i=
s=20
> planned to become compilable with GHC 6.4?

Hi Robert,

I believe that as of today, the CVS version is compilable (using=20
configure and make) with GHC 6.4. It is, however, not installable=20
because the Cabal support is not working properly yet. HaskellDB needs=20
to be Cabalized, and it should probably be split up into several Cabal=20
packages, one common one, and one for each backend, like HSQL is. I'll=20
try to work on it after I get back from my summer vacation (which I'm in=20
the middle of).

/Bj=F6rn

[Haskelldb-users] Haskelldb and GHC 6.4

[Robert v. H. <rh...@cs...>]

Hi all,

I am wondering: is there any kind of time frame yet on when HaskellDB is 
planned to become compilable with GHC 6.4?

Regards,
Robert

Re: [Haskelldb-users] Compiling with GHC 6.4, HSQL, and MySQL

[Krasimir A. <ka2...@ya...>]

Hello, Guys

The Cabal support in HSQL is still half-baked. I was a
little bit off in the last few months but now I will
have more free time and I will complete the next HSQL
release. I am sorry for this inconvenience but after
all I am working on HSQL only in my free time. I also
thought how to separate the different backends in
HSQL. The new Cabalized version will have multiple
packages. One common and one for each backend. These
will be really small - usually only one module. The
advantage is that you will be able to have multiple
backends installed but your program will be linked
only with the backend which you like. I saw that under
Linux if you have multiple backends installed but you
are using only one of them then the program will be
linked to all backends. This isn't the case with
Windows. Under Windows the linker will choice the
right backend automatically. I don't know why this
happens under Linux but it seems that the above is the
only available solution. Another advantage is that
when one day we have real support for Haskell .dll/.so
compilation then I will be able to load the backend
package dynamically. I hope that this compilation mode
will be available soon. It is already working for
MacOS and was working under Windows (currently
requires some kind of repairing).
The disadvantage is that the user will have to build
manually each package. Cabal still doesn't support
shipments.

Cheers,
  Krasimir

--- Bjorn Bringert <bri...@cs...> wrote:

> Robert van Herk wrote:
> > I think that Setup.hs in the repos together with
> the cabal file could be 
> > used to compile with GHC 6.4 and PostgreSQL
> support.
> > 
> > However, I would like to compile with GHC 6.4,
> HSQL, and MySQL (and NO 
> > PostgreSQL).
> > 
> > When I try runhaskell Setup.hs build, I get:
> > 
> > $ runhaskell Setup.hs build
> > Preprocessing library haskelldb-0.9...
> > can't find source for
> Database.HaskellDB.HSQL.PostgreSQL in ["build/ghc"]
> > 
> > In the output of "runhaskell Setup.hs configure",
> I don't see anything 
> > trying to look for availability of PostgreSQL
> either. Is there an easy 
> > solution to this?
> 
> Short answer: no, there is no easy answer. As far as
> I know anyway.
> 
> Does anyone have an idea about how we should handle
> HSQL providing only 
> some backends, and how we should handle
> conditionally compiling only 
> some backends? This is now done with configure, but
> using plain Cabal 
> would be nice.
> 
> Maybe we could always provide all backends, but use
> CPP to make the 
> unavailable ones dummies that fail at runtime?
> 
> /Björn
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create
> apps using Yahoo!
> Search APIs Find out how you can build Yahoo!
> directly into your own
> Applications - visit
>
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
>
https://lists.sourceforge.net/lists/listinfo/haskelldb-users
> 



		
__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html

Re: [Haskelldb-users] Compiling with GHC 6.4, HSQL, and MySQL

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

Robert van Herk wrote:
> I think that Setup.hs in the repos together with the cabal file could b=
e=20
> used to compile with GHC 6.4 and PostgreSQL support.
>=20
> However, I would like to compile with GHC 6.4, HSQL, and MySQL (and NO=20
> PostgreSQL).
>=20
> When I try runhaskell Setup.hs build, I get:
>=20
> $ runhaskell Setup.hs build
> Preprocessing library haskelldb-0.9...
> can't find source for Database.HaskellDB.HSQL.PostgreSQL in ["build/ghc=
"]
>=20
> In the output of "runhaskell Setup.hs configure", I don't see anything=20
> trying to look for availability of PostgreSQL either. Is there an easy=20
> solution to this?

Short answer: no, there is no easy answer. As far as I know anyway.

Does anyone have an idea about how we should handle HSQL providing only=20
some backends, and how we should handle conditionally compiling only=20
some backends? This is now done with configure, but using plain Cabal=20
would be nice.

Maybe we could always provide all backends, but use CPP to make the=20
unavailable ones dummies that fail at runtime?

/Bj=F6rn

[Haskelldb-users] Re: GHC hang

[John G. <jgo...@co...>]

On Tue, May 31, 2005 at 11:57:54PM +0200, Robert van Herk wrote:
> John Goerzen wrote:
> 
> >Hi,
> >
> >I'm trying to compile WashNGo 2.3.1 on my amd64 machine running GHC 6.4.
> >When compiling HTMLMonad98.hs, ghc hangs.  It's been running over 5
> >minutes now with no output or other activity.  
> > 
> >
> Believe it or not, it isn't hanging, it is compiling. It takes more than 
> 15 minutes to compile (or parse) that file on my AMD 2300. Therefore, 
> better to use ghc --make, which saves the compiled files so you only 
> have to go through this once.

Heh.  OK, I will try again :-)

Funny thing is that I have an i386 chroot on this box, and ghc 6.2
doesn't seem to have any problem with it in that chroot.  I figured it
was a 6.4 regression, but I suppose it does make sense that it could be
an amd64 performance thing (ghc does seem slower on amd64 overall).

-- John

[Haskelldb-users] Re: GHC hang

[Robert v. H. <rh...@cs...>]

John Goerzen wrote:

>Hi,
>
>I'm trying to compile WashNGo 2.3.1 on my amd64 machine running GHC 6.4.
>When compiling HTMLMonad98.hs, ghc hangs.  It's been running over 5
>minutes now with no output or other activity.  
>  
>
Believe it or not, it isn't hanging, it is compiling. It takes more than 
15 minutes to compile (or parse) that file on my AMD 2300. Therefore, 
better to use ghc --make, which saves the compiled files so you only 
have to go through this once.

When you look at the source of HTMLMonad98, you will notice it is 
huuuuuuuuuuuuuuge.

Robert

[Haskelldb-users] Compiling with GHC 6.4, HSQL, and MySQL

[Robert v. H. <rh...@cs...>]

I think that Setup.hs in the repos together with the cabal file could be 
used to compile with GHC 6.4 and PostgreSQL support.

However, I would like to compile with GHC 6.4, HSQL, and MySQL (and NO 
PostgreSQL).

When I try runhaskell Setup.hs build, I get:

$ runhaskell Setup.hs build
Preprocessing library haskelldb-0.9...
can't find source for Database.HaskellDB.HSQL.PostgreSQL in ["build/ghc"]

In the output of "runhaskell Setup.hs configure", I don't see anything 
trying to look for availability of PostgreSQL either. Is there an easy 
solution to this?

Robert

Re: [Haskelldb-users] Something wrong with my subscription

[Robert v. H. <rh...@cs...>]

My subscription started working again...

[Haskelldb-users] Something wrong with my subscription

[Robert v. H. <rh...@cs...>]

Hello all,

I think there may be something wrong with my substription to this 
mailing list. That is: I AM subscribed to the list and "Disable mail" is 
not turned on, yet I do not receive any mail...

Anyways, I saw on the www archive of the mailing list that people were 
replying to my posts. jippiee!! :-)

Shae, I saw that you sent me 2 files that would make it possible to 
compile haskelldb under ghc 6.4. Could you please resend me these files, 
since I cannot get them from the web archive, and, since there is (or 
was) something wrong with my subscription, I didn't get them in my mail 
either :-S. Thanks!

Robert

[Haskelldb-users] Compile errors when compiling from CVS

[Robert v. H. <rh...@cs...>]

Hello,

I get some compile errors when I am comping from CVS. I am using GHC 
6.4, HSQL and MySQL support. This is what I get:

build/ghc/Database/HaskellDB/FieldType.hs:76:24:
    Couldn't match `TypeRep' against `TyCon'
      Expected type: TypeRep
      Inferred type: TyCon
    In the application `mkTyCon "System.Time.CalendarTime"'
    In the first argument of `mkAppTy', namely
        `(mkTyCon "System.Time.CalendarTime")'

build/ghc/Database/HaskellDB/FieldType.hs:79:24:
    Couldn't match `TypeRep' against `TyCon'
      Expected type: TypeRep
      Inferred type: TyCon
    In the application `mkTyCon "Database.HaskellDB.BoundedString"'
    In the first argument of `mkAppTy', namely
        `(mkTyCon "Database.HaskellDB.BoundedString")'

What can be wrong?

Regards,
Robert

Re: [Haskelldb-users] Build error from CVS, and GHC 6.4

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

-- 
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas.   | -- Shae Matijs Erisson

Re: [Haskelldb-users] data structures over tables

[Frederik E. <fre...@a5...>]

On Wed, Apr 13, 2005 at 12:19:23PM +0200, Bjorn Bringert wrote:
> Frederik Eaton wrote:
> >I'm thinking about implementing special indexing data structures over
> >SQL tables in databases that might not support those structures
> >natively, for instance an R-tree for multidimensional range queries (I
> >think mysql supports only up to dimension 2) or a simple balanced tree
> >for fast calculation of a running total of a given column. (data
> >structure links would be to primary key columns of tables)
> 
> Thiat sounds like an interesting project.

I thought about it some more, I think doing it efficiently, minimizing
database communication round-trips as well as file IO, would require
using structures like B-Trees and storing large "blocks" of binary
data in columns and parsing these out on the client side. Not quite as
pretty but still possible.

> >I thought that haskelldb might be a good candidate for such an
> >implementation because of the ability to achieve modularity by
> >composing query functions, and also the potential to minimize context
> >switches by sending large chunks of SQL code to the server at once...
> >But presumably the datatypes would require atomicity in the form of
> >locking or transactions, which haskelldb would have to support, as
> >well as 'if' statements or 'if' functions for logic. An alternative
> >would be to write stored procedures directly in SQL. (can haskelldb
> >generate these?) A separate issue is enforcing type constraints, such
> >as saying that an 'id' value in a certain column can only be used to
> >look up elements of certain other columns, it seems like it could be a
> >capability of haskelldb, is it?
> 
> HaskellDB already has support for transactions (with MySQL I think you 
> need to set the table type correctly for this to work, see the MySQL 
> manual) and if functions. There is no support for stored procedures, 
> though it could be a nice project for someone to look at.
> 
> For the id columns, do you mean that one couldn't get at the actual 
> value, just use it to look up other values? Or what is the type 
> contraint here?

I don't know. I guess you wouldn't *need* the actual value if it was
just for looking up rows in your database, although you might want it
if it's also an index to external entities. So even if it's just an
Int underneath, it could be wrapped in something semi-opaque when
you're manipulating it in HaskellDB to mark the "virtual type", and
this would not be an inconvenience. But I think you already understand
the purpose, there should be various ways of achieving it nicely it if
it's deemed useful. Maybe specifying virtual types as part of the
schema or something,

Frederik

Re: [Haskelldb-users] data structures over tables

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

Frederik Eaton wrote:
> I'm thinking about implementing special indexing data structures over
> SQL tables in databases that might not support those structures
> natively, for instance an R-tree for multidimensional range queries (I
> think mysql supports only up to dimension 2) or a simple balanced tree
> for fast calculation of a running total of a given column. (data
> structure links would be to primary key columns of tables)

Thiat sounds like an interesting project.

> I thought that haskelldb might be a good candidate for such an
> implementation because of the ability to achieve modularity by
> composing query functions, and also the potential to minimize context
> switches by sending large chunks of SQL code to the server at once...
> But presumably the datatypes would require atomicity in the form of
> locking or transactions, which haskelldb would have to support, as
> well as 'if' statements or 'if' functions for logic. An alternative
> would be to write stored procedures directly in SQL. (can haskelldb
> generate these?) A separate issue is enforcing type constraints, such
> as saying that an 'id' value in a certain column can only be used to
> look up elements of certain other columns, it seems like it could be a
> capability of haskelldb, is it?

HaskellDB already has support for transactions (with MySQL I think you=20
need to set the table type correctly for this to work, see the MySQL=20
manual) and if functions. There is no support for stored procedures,=20
though it could be a nice project for someone to look at.

For the id columns, do you mean that one couldn't get at the actual=20
value, just use it to look up other values? Or what is the type=20
contraint here?

/Bj=F6rn

[Haskelldb-users] Build error from CVS, and GHC 6.4

[Robert v. H. <rh...@cs...>]

Hi there,

I have two questions:

First of all, is the CVS version of HaskellDB already supporting the new 
package system of GHC 6.4?
And second, I get a build error when trying to compile the source that 
is in CVS:

make[1]: Entering directory `/home/robert/soft/src/haskell/build/haskelldb'
/home/robert/soft/bin/ghc -O2 -fglasgow-exts 
-fallow-overlapping-instances -i./build/ghc -package-name haskelldb -c 
build/ghc/Database/HaskellDB/FieldType.hs 
build/ghc/Database/HaskellDB/BoundedString.hi -o 
build/ghc/Database/HaskellDB/FieldType.o

build/ghc/Database/HaskellDB/FieldType.hs:76:24:
    Couldn't match `TypeRep' against `TyCon'
      Expected type: TypeRep
      Inferred type: TyCon
    In the application `mkTyCon "System.Time.CalendarTime"'
    In the first argument of `mkAppTy', namely
        `(mkTyCon "System.Time.CalendarTime")'

build/ghc/Database/HaskellDB/FieldType.hs:79:24:
    Couldn't match `TypeRep' against `TyCon'
      Expected type: TypeRep
      Inferred type: TyCon
    In the application `mkTyCon "Database.HaskellDB.BoundedString"'
    In the first argument of `mkAppTy', namely
        `(mkTyCon "Database.HaskellDB.BoundedString")'
make[1]: *** [build/ghc/Database/HaskellDB/FieldType.o] Error 1
make[1]: Leaving directory `/home/robert/soft/src/haskell/build/haskelldb'
make: *** [all-ghc] Error 2

What is wrong?

Regards,
Robert