Haskell Toolkit

Robert van Herk wrote:
> However, when I do ghci -package hsql, I get:
> Loading package base ... linking ... done.
> Loading package hsql ... ghc-6.2.2: can't load .so/.DLL for: c=20
> (/usr/lib/libc.so: invalid ELF header)

I belive you are the second person in the world to see this error. If=20
you Google for it, all you get is a log of me asking about it in the=20
#haskell irc channel. The problem is that for some reason, on some=20
machines mysql-config reports that it needs -lc. This means that=20
/usr/lib/ghc-6.2.2/package.conf will have "c" in extra_libraries, which=20
means that ghci will try to load libc.so. This is completely redundant,=20
and causes the error above. The simplest solution is to hand-edit=20
package.conf after installing HSQL and remove "c" from extra_libraries=20
in the hsql section. We should probably put a fix for this in the=20
configure script.

/Bj=F6rn

> I guess that means that in a concurrent application I should use some
> other object to identify the main database internally than a
> connection, maybe an 'IO Connection'...?

Until I get "Too many connections". Sigh.

Frederik Eaton wrote:
>>You might want to be careful with collectRowsAsync. We have the same=20
>>thing in HaskellDB, and it turns out to be a problem with some database=
s=20
>>if you run a second query without getting all that data from the first=20
>>one. I think MySQL with the native drivers does it for example, but not=
=20
>>with ODBC.
>=20
> What are the symptoms?

If you already have an open result and try to run another query, you=20
will get an expcetion with the MySQL drivers.

> What I'm seeing is that if I run closeStatement before reading all the
> rows from a query, it goes ahead and reads the rest of the rows
> silently, which is bad if there are millions of rows. For instance, if
> there is an error, like if I request a field with the wrong type, then
> since these are caught by a 'finally' clause in getFieldValue and
> trigger a closeStatement, the error message isn't printed (by
> 'handleSql print' in main) until the whole table is read in, several
> minutes later.

That doesn't seem like what you'd expect. Bug in the driver, or HSQL mayb=
e?

> I'm trying to get MyODBC installed - this is necessary using MySQL
> through ODBC, right? - to see if the behavior is any different, since
> you seemed to imply it would be less problematic.

Well, yes and no. You don't get the exception like with the MySQL=20
driver, but the reason for that is that the MyODBC driver seems to fetch=20
the entire result set from the server straight away and keep it locally.=20
So you can have two open queries, but the only thing you gain from=20
laziness is that the data you never use will be in C code, not Haskell,=20
and thus take up less space. But that of course won't help if the=20
results are larger that you local RAM for example.

/Bj=F6rn

> If you already have an open result and try to run another query, you 
> will get an expcetion with the MySQL drivers.

OK, this was the subject of my other recent message.

> >What I'm seeing is that if I run closeStatement before reading all the
> >rows from a query, it goes ahead and reads the rest of the rows
> >silently, which is bad if there are millions of rows. For instance, if
> >there is an error, like if I request a field with the wrong type, then
> >since these are caught by a 'finally' clause in getFieldValue and
> >trigger a closeStatement, the error message isn't printed (by
> >'handleSql print' in main) until the whole table is read in, several
> >minutes later.
> 
> That doesn't seem like what you'd expect. Bug in the driver, or HSQL maybe?

I don't know, but the HSQL code looks like it's doing the right thing.
OTOH, MySQL should do better than that...

> >I'm trying to get MyODBC installed - this is necessary using MySQL
> >through ODBC, right? - to see if the behavior is any different, since
> >you seemed to imply it would be less problematic.
> 
> Well, yes and no. You don't get the exception like with the MySQL 
> driver, but the reason for that is that the MyODBC driver seems to fetch 
> the entire result set from the server straight away and keep it locally. 
> So you can have two open queries, but the only thing you gain from 
> laziness is that the data you never use will be in C code, not Haskell, 
> and thus take up less space. But that of course won't help if the 
> results are larger that you local RAM for example.

Ah, that's terrible. So I have no reason to use ODBC.

Frederik

-- 
http://ofb.net/~frederik/