Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi Jakob,

(moving back to the list where you apparently meant to send your mail)

Jakob Beetz writes:
 > 1. I was not able to get make test through, none of the subtests in 
 > test.pl was able to connect to the database when sending plain passwords 
 > in the coresponding subs in  Client.pm ( $cmd .= "-w $self->{passwd} "; 
 > ).  I could partly "solve" this by replacing the above lines with $cmd 
 > .= "-w $self->{numberized_passwd} "; which resolved the issue for most 
 > tests (however  10..21 still fails with "failed to connect to database 
 > server", strange enough the second call to $clientc->refdb_addref passes 
 > a different -w $self->{numberized_passwd} to refdbd after 9..10 
 > succeeded...)
 > 

Your fix was absolutely correct. I never came across these typos as I
run tests mostly on a SQLite database which doesn't care about
username and password.

$self->{numberized_passwd} will be different for each test as each
connection to refdbd will result in a fresh scramble string which is
used to encode the password.

 > 
 > 2. after "solving" this issue, refdb_addref could not be executed, 
 > stating "cannot lock tables" for  "testuser" created during the 
 > execution of test.pl. What I did was adding LOCK TABLES to the GRANT 
 > statements in refdba.c line 1176 ff. (However, as I did not want to 
 > touch the default rights to refdb1 I manually added LOCK TABLES for 
 > "testuser" (for the call  "LOCK TABLES [...] refdb1.t_journal_words 
 > WRITE" in 9..21))
 > 

This fix should not be required unless there is a MySQL version issue
at work (I still use a 3.23 release). The real problem was an
uninitialized pointer that happened to be NULL in all my previous
tests. Besides, the reference data used in make test did not match the
latest risx.dtd and thus would have given strange results anyway.

I've fixed all these issues. Please test the new prereleases as
announced in a separate mail and see whether your table locking issue
still persists.

thanks for your testing
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de