refdb-users — List for RefDB users

Re: [Refdb-users] MySQL v. PostgreSQL

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

Torsten Bronger writes:
 > > I'd like to see your RefDB setup (run refdb-bug to create an
 > > overview of your setup)
 > 
 > I can't find this program, but my config file says

Weird. Should be installed in /usr/local/bin/refdb-bug. Anyway, the
following config file is the one we need to look at, and it looks ok.

 > 
 > refdblib /usr/local/share/refdb
 > main_db	refdb
 > serverip	localhost
 > dbsport		5432
 > dbserver	pgsql
 > dbpath		/usr/local/var/lib/refdb/db
 > port	9734
 > logfile /usr/local/var/log/refdbd.log
 > logdest file
 > loglevel info
 > pidfile		/usr/local/var/run/refdbd.pid
 > remoteadmin f
 > remoteconnect f
 > keep_pnames t
 > keyword_scan t
 > dbi_driverdir /usr/lib/dbd
 > db_encoding	UTF-8
 > in_encoding	UTF-8

 > http://www-users.rwth-aachen.de/Torsten.Bronger/mysql.log
 > http://www-users.rwth-aachen.de/Torsten.Bronger/pgsql.log
 > 

Thanks for providing these logs. I've compared them with each other,
and I've compared them to what my setup produces. The main difference
that I see in your logs is, strange enough, in the pgsql log:

input encoding is:
UTF-8
database encoding is:
UTF8

See the missing dash? This does not happen on my installation. The
reason appears to be a change in PostgreSQL's character encoding
support between 8.0.19 (which I run) and 8.1 or later (which I bet you
are running). 8.0.x used "UNICODE" as the encoding name for UTF-8
data. 8.1 changed this to "UTF8" ("UNICODE" is still recognized as an
alias). The pgsql driver did not know about this change until about
five minutes ago. All libdbi drivers contain routines to translage the
database engine-specific encoding names to IANA names. If a databae
encoding name is not recognized, no error is thrown but the name is
passed as is. This is why "UTF8" shows up in your logs. The weird
thing is that this should cause an iconv error, as "UTF8" is not a
valid encoding name supported by iconv. What does

iconv -l|grep -i utf8

return on your system?

In any case, if that were a problem, I'd expect PostgreSQL to cause unicode
problems instead of MySQL.

Your MySQL log looks perfectly ok though:

no character encoding conversion required
database encoding is:
UTF-8

This shows that refdbd does not convert the encoding, as it expects
incoming data as UTF-8 and inserts them into the database engine as
is.

Did you check those datasets which you inserted when creating the
above logs? Is it possible that you changed your setup at some point,
and only datasets fail which you added before that point?

I've also checked the variables used by my MySQL setup. I don't see a
difference to your setup, especially character-set-server and
collation-server are identical.

regards,
Markus

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

Re: [Refdb-users] MySQL v. PostgreSQL

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

Torsten Bronger writes:
 > Plase also test whether "M.lsch,A" succeeds.  Maybe MySQL just
 > compares "MXXlsch" with "MXXlsch" (with XX being the UTF-8
 > representation of ü) and this matches.
 > 

No, it always takes two dots (M..lsch). Works in the Emacs frontend
and on the command line. The MySQL regexp engine apparently performs a
bytewise comparison instead of treating multibyte unicode characters
as entities.

regards,
Markus

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

Re: [Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Torsten Bronger writes:

> [...]
>
> http://www-users.rwth-aachen.de/Torsten.Bronger/mysql.log
> http://www-users.rwth-aachen.de/Torsten.Bronger/pgsql.log
>
> However, take them with a grain of salt because they are copied
> from the shell.  I don't know whether the shell can "repair" or
> interpret encodings.  Anyway, it should be sufficient for
> comparing both.

This is no problem anymore; I re-created them in a way that any
tempering is impossible.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Markus Hoenicka writes:

> [...]
>
> I'd like to see your RefDB setup (run refdb-bug to create an
> overview of your setup)

I can't find this program, but my config file says

refdblib /usr/local/share/refdb
main_db	refdb
serverip	localhost
dbsport		5432
dbserver	pgsql
dbpath		/usr/local/var/lib/refdb/db
port	9734
logfile /usr/local/var/log/refdbd.log
logdest file
loglevel info
pidfile		/usr/local/var/run/refdbd.pid
remoteadmin f
remoteconnect f
keep_pnames t
keyword_scan t
dbi_driverdir /usr/lib/dbd
db_encoding	UTF-8
in_encoding	UTF-8

Only dbsport and dbserver are different for MySQL.

> and the refdbd log to see what happens during addref, ideally with
> both database engines.

http://www-users.rwth-aachen.de/Torsten.Bronger/mysql.log
http://www-users.rwth-aachen.de/Torsten.Bronger/pgsql.log

However, take them with a grain of salt because they are copied from
the shell.  I don't know whether the shell can "repair" or interpret
encodings.  Anyway, it should be sufficient for comparing both.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] MySQL v. PostgreSQL

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

Quoting Torsten Bronger <br...@ph...>:

> Mhhh ... this sounds logical.  However, the question remains why the
> very same Python program and the very same RefDB didn't exhibit this
> behaviour with PostgreSQL.
>

In that case I suppose that MySQL and PostgreSQL use different default  
encodings, or use different strategies to handle incoming data. Looks  
like PostgreSQL writes your data as they come in, whereas MySQL  
transforms them. I'd like to see your RefDB setup (run refdb-bug to  
create an overview of your setup) and the refdbd log to see what  
happens during addref, ideally with both database engines.

regards,
Markus

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

Re: [Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Markus Hoenicka writes:

> [...]
>
> [...] I cannot reproduce this problem here using the Emacs
> frontend and MySQL 5.0.67. Running a regexp query through said
> frontend sends the following command to a shell:
>
> /home/markus/prog/refdb/refdb/trunk/src/refdbc -c stdout -C getref
> ":AX:~'Mülsch,A'" -E UTF-8 -d stemmat -t ris
>
> This command correctly returns one dataset. I'll try to reproduce
> this problem tomorrow using some unicode-aware terminals on a
> windoze box.

Plase also test whether "M.lsch,A" succeeds.  Maybe MySQL just
compares "MXXlsch" with "MXXlsch" (with XX being the UTF-8
representation of ü) and this matches.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Markus Hoenicka writes:

> Quoting Torsten Bronger <br...@ph...>:
>
>> 3.  ":AU:~M....ller" was found.  (It must have been exactly four
>>     dots.)
>
> That should ring a bell. If you need four dots, the data in your  
> database may be "double encoded" unicode.

Mhhh ... this sounds logical.  However, the question remains why the
very same Python program and the very same RefDB didn't exhibit this
behaviour with PostgreSQL.

I'll switch back to MySQL and test it this evening (CET).

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] MySQL v. PostgreSQL

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

Quoting Torsten Bronger <br...@ph...>:

> 3.  ":AU:~M....ller" was found.  (It must have been exactly four
>     dots.)
>

That should ring a bell. If you need four dots, the data in your  
database may be "double encoded" unicode. That is, you somehow manage  
to send unicode data (using two byte for the umlaut), but either RefDB  
or your database engine thinks it still has to convert the data into  
unicode. This turns each of these two bytes again into two bytes. It  
would be helpful to turn on refdbd debug output (refer to the -e and  
-l switches or the equivalent config file variables,  
http://refdb.sourceforge.net/manual/re02.html) to see if and why  
refdbd encodes your data again. Just add some data with an umlaut  
using addref and send the log.

regards,
Markus

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

Re: [Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Markus Hoenicka writes:

> Torsten Bronger writes:
>
>> However, yesterday I made my Python client Unicode-proof and
>> found out that MySQL has significant trouble with non-ASCII
>> characters in regexps, see
>> <http://bugs.mysql.com/bug.php?id=30241>.  In my opinion this is
>> critical for RefDB applications because it means that queries
>> like ":AU:~Müller" will always fail.
>
> Which mysqld version are you running?

5.0.67, too.

> I cannot reproduce this problem here using the Emacs frontend and
> MySQL 5.0.67. Running a regexp query through said frontend sends
> the following command to a shell:
>
> /home/markus/prog/refdb/refdb/trunk/src/refdbc -c stdout -C getref
> ":AX:~'Mülsch,A'" -E UTF-8 -d stemmat -t ris
>
> This command correctly returns one dataset.

That's really odd.  My complete result was: 

1.  ":AU:~Müller" was not found.

2.  ":AU:~M.ller" was not found.

3.  ":AU:~M....ller" was found.  (It must have been exactly four
    dots.)

4.  ":AU:~ller" was found.

5.  I think that even ":AU:~Müller,A." (which is the complete name)
    was not found.

6.  ":AU:=Müller,A." was found.

With PostgreSQL, all except (3.) were found.  I send in UTF-8
encoding, the "-E" option was always set.  My my.cnf says:

    default-character-set = utf8
    default-storage_engine = innodb
    character-set-server=utf8
    collation-server=utf8_unicode_ci
    init_connect='set collation_connection = utf8_unicode_ci;'

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

[Refdb-users] MySQL v. PostgreSQL

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

Torsten Bronger writes:
 > However, yesterday I made my Python client Unicode-proof and found
 > out that MySQL has significant trouble with non-ASCII characters in
 > regexps, see <http://bugs.mysql.com/bug.php?id=30241>.  In my
 > opinion this is critical for RefDB applications because it means
 > that queries like ":AU:~Müller" will always fail.
 > 

Which mysqld version are you running? I cannot reproduce this problem
here using the Emacs frontend and MySQL 5.0.67. Running a regexp query
through said frontend sends the following command to a shell:

/home/markus/prog/refdb/refdb/trunk/src/refdbc -c stdout -C getref
":AX:~'Mülsch,A'" -E UTF-8 -d stemmat -t ris

This command correctly returns one dataset. I'll try to reproduce this
problem tomorrow using some unicode-aware terminals on a windoze box.

regards,
Markus


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

[Refdb-users] MySQL v. PostgreSQL

[Torsten B. <br...@ph...>]

Hallöchen!

Until today, I used MySQL.  Normally it doesn't matter much whether
you use MySQL or PostgreSQL, so six months ago, I chose the one with
the bigger community.

However, yesterday I made my Python client Unicode-proof and found
out that MySQL has significant trouble with non-ASCII characters in
regexps, see <http://bugs.mysql.com/bug.php?id=30241>.  In my
opinion this is critical for RefDB applications because it means
that queries like ":AU:~Müller" will always fail.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] getref leads to an invalid SELECT

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

Torsten Bronger writes:
 > Sorry, I forgot to send the number of bytes.  However, what should I
 > send?  len(query_string) is too less, len(query_string)+1 seems to
 > work, len(query_string)+4 seems to be what the Perl client sends (I
 > can barely read Perl).
 > 

This is correct. The length of the query string plus the terminating
NULL bytes is the size of the buffer which refdbd needs to allocate in
order to read the query. However, if you succeed in tricking the
server to send garbage to the database engine, something is wrong on
the server side. I'll have to look into this. refdbd should refuse
getref commands with an improper buffer size.

regards,
Markus

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

Re: [Refdb-users] getref leads to an invalid SELECT

[Torsten B. <br...@ph...>]

Hallöchen!

Torsten Bronger writes:

> Hallöchen!
>
> I try using getref through a socket.  The communication is as
> follows:
>
> '6\x00\x00\x00\x00' ==>
> <== '000012-34-21-32\x00\x00\x00\x00'
> '000getref -d biblio -u root -w 110069038082057\x00\x00\x00\x00' ==>
> <== '000'
> '000:AU:~Ast\x00\x00\x00\x00' ==>
> <== '234'

Sorry, I forgot to send the number of bytes.  However, what should I
send?  len(query_string) is too less, len(query_string)+1 seems to
work, len(query_string)+4 seems to be what the Perl client sends (I
can barely read Perl).

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

[Refdb-users] getref leads to an invalid SELECT

[Torsten B. <br...@ph...>]

Hallöchen!

I try using getref through a socket.  The communication is as
follows:

'6\x00\x00\x00\x00' ==>
<== '000012-34-21-32\x00\x00\x00\x00'
'000getref -d biblio -u root -w 110069038082057\x00\x00\x00\x00' ==>
<== '000'
'000:AU:~Ast\x00\x00\x00\x00' ==>
<== '234'


(==> is sent by my client, <== is received by my client.)  The
question is why I get the 234.  It means "select failed".  The
refdbd says:


--8<---------------cut here---------------start------------->8---
output encoding is:
UTF-8
SELECT DISTINCT t_refdb.refdb_id, [...] t_refdb.refdb_citekey FROM t_refdb WHERE refdb_type!='DUMMY' AND rset>

<charset name="cpA ORDER BY t_refdb.refdb_id
1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<charset name="cpA ORDER BY t_refdb.refdb_id' at line 3
select failed
--8<---------------cut here---------------end--------------->8---


It looks like the memory area of the query was polluted with some
garbage.  But something else is equally strange to me.  If I request
via refdbc, the daemon says:


--8<---------------cut here---------------start------------->8---
output encoding is:
UTF-8
SELECT VERSION()
SELECT DISTINCT t_xauthor.refdb_id FROM t_xauthor INNER JOIN t_author ON t_author.author_id=t_xauthor.author_id WHERE t_xauthor.xauthor_type='part' AND t_author.author_name RLIKE BINARY 'Ast'
SELECT DISTINCT t_refdb.refdb_id, [...] t_refdb.refdb_citekey FROM t_refdb WHERE refdb_type!='DUMMY' AND t_refdb.refdb_id IN (1) ORDER BY t_refdb.refdb_id
[...]
command processing done, finish dialog now
--8<---------------cut here---------------end--------------->8---


So, the first SELECT DISTINCT (which finds the IDs) is missing in
the first version.  Am I doing something very nasty here or is this
a bug?

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

[Refdb-users] User is not properly added?

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

Torsten Bronger writes:
 > The user _was_ added to the MySQL database (because I can see him in
 > the MySQL administration tool), but why doesn't "listuser" find him?

refdbd does not check the underlying database engine, as e.g. SQLite
does not have any concept of access control. Instead, it checks for
entries in the t_user table of the current database. These entries are
created no sooner than a user adds or picks references though. So
immediately after adding a new user listuser won't find him. Think of
the listuser command as "who has entries in the database" rather than
"who has access to the database".

regards,
Markus

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

[Refdb-users] User is not properly added?

[Torsten B. <br...@ph...>]

Hallöchen!

How can this happen:

    bronger@wilson:~/src/pyrefdb/main$ refdba -c stdout -C adduser -d biblio -W secret bunny
    236
    237:bunny@localhost:biblio
    999:1 added:0 failed
    bronger@wilson:~/src/pyrefdb/main$ refdba -c stdout -C listuser -d biblio
    999:0

The user _was_ added to the MySQL database (because I can see him in
the MySQL administration tool), but why doesn't "listuser" find him?

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] Problems with "addref" via socket

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

Torsten Bronger writes:
 > Okay, I tested heavily and found out how it works.  In contradiction
 > to <http://refdb.sourceforge.net/manual/ch23s03.html#id2657099>, the
 > 408 has a trailing result message.  (Although it is sent with a
 > slight delay.)

This is correct. refdbd should print the total number of datasets
after each 408/413 message.

 > Moreover, while the 403 has terminated content, it
 > is always empty.

As far as I can see, the content is always empty if you run the client
command "addref". If you run "checkref" instead, the duplicate report
is inserted here.

 > 
 > By the way, I wonder what the 404 is for.
 > 
 > Are the docs out of sync with the daemon?

Regrettably so. 404 is not used in the addref command at all. It is
used in getref and getbib though.

I'll fix these errors in the svn versions of the docs.

If you keep bumping into protocol problems, it may be helpful to edit
src/connect.c. The functions send_status() and read_status() contain
commented-out printf() calls which may be helpful to see what the
server and the C client do.

regards,
Markus

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

Re: [Refdb-users] Problems with "addref" via socket

[Torsten B. <br...@ph...>]

Hallöchen!

Torsten Bronger writes:

> Trying to use "addref"
> (http://refdb.sourceforge.net/manual/ch23s03.html#id2657099)
> through a socket, I get a 406 instead of a 403 after having sent
> the 402.  What does it mean and how does it fit into the protocol?
> It isn't documented at all as far as I can see.

Okay, I tested heavily and found out how it works.  In contradiction
to <http://refdb.sourceforge.net/manual/ch23s03.html#id2657099>, the
408 has a trailing result message.  (Although it is sent with a
slight delay.)  Moreover, while the 403 has terminated content, it
is always empty.  The complete communication in case of adding
something twice is:

'6\x00\x00\x00\x00' ==>
<== '000'
<== '210-82-39-61'
<== '\x00\x00\x00\x00'
'000addref -d biblio -u root -w 104112047125110\x00\x00\x00\x00' ==>
<== '000'
'000307\x00\x00\x00\x00' ==>
<== '000'
u'\nTY  - JOUR\nAU  - Astakhov,O.\nAU  - [...]ER  - \n' ==>
<== '408'
<== '406:1:Astakhov2006wa\n408:1\n\x00\x00\x00\x00'
'000307\x00\x00\x00\x00' ==>
<== '000'
u'\nTY  - JOUR\nAU  - Astakhov,O.\nAU  - [...]ER  - \n' ==>
<== '408'
<== '406:2:Astakhov2006xa\n408:2\n\x00\x00\x00\x00'
'402' ==>
<== '403'
<== '\x00\x00\x00\x00'
'000' ==>
<== '000'
<== '999:2 added:0 skipped:0 failed\n\x00\x00\x00\x00'
'000' ==>

By the way, I wonder what the 404 is for.

Are the docs out of sync with the daemon?

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

[Refdb-users] Problems with "addref" via socket

[Torsten B. <br...@ph...>]

Hallöchen!

Trying to use "addref"
(http://refdb.sourceforge.net/manual/ch23s03.html#id2657099) through
a socket, I get a 406 instead of a 403 after having sent the 402.
What does it mean and how does it fit into the protocol?  It isn't
documented at all as far as I can see.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] Python module

[Torsten B. <br...@ph...>]

Hallöchen!

Bruce D'Arcus writes:

> [...]
>
>> However, the first step is a standalone module talking with
>> refdbd.  Is it better to communicate via TCP or better to call
>> refdbc?  TCP seems more elegant, however, I haven't any
>> experience with low-level networking.
>>
>> What's the better source of inspiration?  The Ruby or the Perl
>> module?
>
> But, as with Ruby on Rails, Django's benefit mostly lies in the
> mapping between DB tables, Python objects, and the UI (for
> example, the automatic admin).  So am not sure either of these are
> good examples? I guess it depends on what you want to do ...

I just need an example for the low-level stuff.  It is supposed to
be independent of the Django effort.  If this low-level module
works, I know rather well what to do on the Django level.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] Python module

[Bruce D'A. <bda...@gm...>]

On Mon, Feb 2, 2009 at 5:10 AM, Torsten Bronger
<br...@ph...> wrote:
> Hallöchen!
>
> Has anyone already written a Python module for RefDB?
>
> I'm thinking about a Django app for RefDB because we could need
> RefDB in our institute and we have already Django running.

Django's sweet!

> However, the first step is a standalone module talking with refdbd.
> Is it better to communicate via TCP or better to call refdbc?  TCP
> seems more elegant, however, I haven't any experience with low-level
> networking.
>
> What's the better source of inspiration?  The Ruby or the Perl
> module?

But, as with Ruby on Rails, Django's benefit mostly lies in the
mapping between DB tables, Python objects, and the UI (for example,
the automatic admin).  So am not sure either of these are good
examples? I guess it depends on what you want to do ...

Bruce

Re: [Refdb-users] Python module

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

Quoting Torsten Bronger <br...@ph...>:

> However, the first step is a standalone module talking with refdbd.
> Is it better to communicate via TCP or better to call refdbc?  TCP
> seems more elegant, however, I haven't any experience with low-level
> networking.
>

There are basically two considerations: speed and simplicity. If you  
expect lots of accesses, a native implementation of the protocol is  
likely to be faster, as you don't have to create a new process for  
each RefDB command called. On the other hand, the client/server  
protocol may be cumbersome to implement and to maintain. The  
interfaces of the command line clients are less likely to change, and  
they are usually simple to call from scripting languages.

> What's the better source of inspiration?  The Ruby or the Perl
> module?
>

There is also a (not-so-obvious) PHP library to steal from. See  
"phpweb/includes/refdblib.inc.php" in the RefDB sources. This is  
another straightforward example of a library which just calls the C  
clients.

Either way, I'll be happy to help if there are questions regarding the  
client/server protocol or the C client interface.

regards,
Markus

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

[Refdb-users] Python module

[Torsten B. <br...@ph...>]

Hallöchen!

Has anyone already written a Python module for RefDB?

I'm thinking about a Django app for RefDB because we could need
RefDB in our institute and we have already Django running.

However, the first step is a standalone module talking with refdbd.
Is it better to communicate via TCP or better to call refdbc?  TCP
seems more elegant, however, I haven't any experience with low-level
networking.

What's the better source of inspiration?  The Ruby or the Perl
module?

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...

Re: [Refdb-users] Cannot create database in MySQL

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

Quoting Tom Hanlon <to...@fu...>:

> If I understand correctly the goal is a package, deb or RPM that works
> with a dependency of MySQL as a package also and whatever version the
> package requires.
>
> Meaning..
>
> apt-get install refdb..
>
> leads to a MySQL dependency and then the apt-get installs MySQL and we
> are good to go ?
>

not quite. RefDB can use a variety of database engines by means of  
libdbi. So installing a refdb (or refdb-server, as Debian tends to  
split client/server programs into its components) package should pull  
in libdbi, which may or may not be available in a reasonable version.

> Do you use Stored procedure or user created functions ?

no

> Does your DB script that creates the Refdb Database have any
> "create procedure, create function, statements ? "

no

> Are you using foreign keys or transactions ?

no and yes. RefDB uses a wrapper function which is a no-op for  
database engines without transaction support. With MySQL, RefDB always  
uses transactions as these seem to be silently ignored if the table  
engine does not support them.

> If you are are you specifying the table engine = innodb in you create
> table statements.
>

not at this time. RefDB uses whichever engine is set as default in  
MySQL and does not rely on any features not supported by the simplest  
one (MyISAM) as of 5.0.

> Are you using timestamp fields. No big deal here, just the defaults for
> that datatype have been switched around a bit, so the definition of the
> column is _not_ backward compatible, but the funtionality usually is.
>

The t_meta table uses a datetime field which is filled with  
UTC_TIMESTAMP at the time of creation and with a strftime() generated  
string whenever the table is updated. I'm not sure whether your  
concerns about timestamp apply here.

> I have not installed refdb in a couple of years, but I have been
> working with MySQL quite a bit, so I can help out with understanding
> MySQL changes over the years.
>

Your help will be much appreciated. As far as I know the changes in  
the 5.x series have been quite substantial, and it is quite hard to  
keep track if you're not working with MySQL directly. Of course, the  
best way to find out is to install and test-drive a recent RefDB  
version...

regards,
Markus

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

Re: [Refdb-users] Cannot create database in MySQL

[Tom H. <to...@fu...>]

Here is a list of reserved words in MySQL 5.1

http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html

If I understand correctly the goal is a package, deb or RPM that  
works with a dependency of MySQL as a package also and whatever  
version the package requires.

Meaning..

apt-get install refdb..

leads to a MySQL dependency and then the apt-get installs MySQL and  
we are good to go ?

Same goes for RedHat..

Yum install refdb ...
  dependency check and install of MySQL.

This seems reasonable.

Answer the following questions and I can try to help you to make sure  
your DB tables are backwards compatible.

Do you use Stored procedure or user created functions ?
Does your DB script that creates the Refdb Database have any
"create procedure, create function, statements ? "

Are you using foreign keys or transactions ?
If you are are you specifying the table engine = innodb in you create  
table statements.

Are you using timestamp fields. No big deal here, just the defaults  
for that datatype have been switched around a bit, so the definition  
of the column is _not_ backward compatible, but the funtionality  
usually is.

I have not installed refdb in a couple of years, but I have been  
working with MySQL quite a bit, so I can help out with understanding  
MySQL changes over the years.

Best regards,

Tom Hanlon

On 31 Jan 2009, at 11:50, Markus Hoenicka wrote:

> Torsten Bronger writes:
>> Secondly, the name "references" is bad for the database because it
>> seems to be a reserved word or something like that (unfortunately,
>> at the same time it's a good name for a references DB ;-).  With
>> "biblio", it worked.
>
> According to the MySQL manual "references" is a clause in the
> "alter table" syntax, so it is indeed a reserved word. I'll add this
> to the documentation as it is all too easy to get trapped here.
>
>>
>> However, I run into trouble here and there because "deb
>> http://refdb.sourceforge.net/debian/svn testing main" gives me an
>> outdated version (from March 2007 or so).  Is it feasible to update
>> this?  If not, I'm highly probably able to install the SVN version.
>> :)
>>
>
> Unfortunately RefDB has to make do without a Debian maintainer. We
> can't update the .debs unless someone "in the know"
> volunteers. However, the svn version or the latest prerelease should
> work fine. RefDB does not install stuff in weird places, and a "make
> uninstall" should remove most traces of it from your system if you
> ever want to get rid of it.
>
> regards,
> Markus
>
> -- 
> Markus Hoenicka
> mar...@ca...
> (Spam-protected email: replace the quadrupeds with "mhoenicka")
> http://www.mhoenicka.de
>
> ---------------------------------------------------------------------- 
> --------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Refdb-users mailing list
> Ref...@li...
> https://lists.sourceforge.net/lists/listinfo/refdb-users