[libdbi-users] Feedback and Questions [resend]
[I had mail troubles and are now re-sending this message. Hopefully it doesn't produce dulicates...] Hi there, I have just implemented libdbi in my rsyslog project (http://www.rsyslog.com). I wanted to provide some feedback and also post some questions ;) Rsyslog is a vastly enhanced modular syslogd. It provides a plugin-interface. I am using libdbi for database-ignorant writing of syslog records. This is done inside a rsyslog output plugin, which in itself is a slim code layer. If anybody is interested, a quick look can be found at its cvsweb: http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/plugins/omlibdbi/omli bdbi.c?revision=1.5view=markup I would like to thank you for the nice piece of software. I was able to create the rsyslog plugin in roughly 3 hours and most of this time was spent on evaluating why it did load drivers with the Fedora 8 default packages. It turned out that the reason was that rsyslog dlloads its own plugin which than calls libdbi. I did an install from the most recent source and that fixed the problem. I have to admit I am still a bit concerned that this causes headaches to my users, but I guess this problem will disappear as the distros begin to pick up the most recent libdbi version. Now to the questions: As I said, rsyslog itself uses plugins. I have no control over who writes and loads which plugins (neither would I like to have to ;)). What happens if another (maybe not-yet-written) plugin also uses libdbi and ALSO calls dbi_initialize()? I guess this is not supported. If so, is there any way inside libdbi to handle that situation. Remember, I can not link the rsyslog core to libdbi, because that would pull in this dependency on any system that runs rsyslog as the default syslogd (currently fedora core 8, debian in discussion, others probably follow). A second question is on the status of the Ingres/mSQL and Oracle drivers. I hope it is OK to post here (it's a one-timer and I'd like to save me another mailing list subscription). I got the impression that at least the Oracle driver can be used in practice (I don't have any of these systems to verify). I would appreciate if you can provide my any advise that I can pass on to my users. rsyslog uses very few driver calls, it just opens the connection and then issues queries with insert statements. No query results are ever used or read. Thanks again for the nice software and I am looking forward to your replies. Rainer Gerhards - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
[libdbi-users] Feedback and Questions [resend]
Rainer Gerhards writes: As I said, rsyslog itself uses plugins. I have no control over who writes and loads which plugins (neither would I like to have to ;)). What happens if another (maybe not-yet-written) plugin also uses libdbi and ALSO calls dbi_initialize()? I guess this is not supported. If so, Do you have any experimental data which indicate that there will be a problem? I don't mean to claim that there is no problem, but I reckon that both plugins, when linked to libdbi, would load the drivers separately and maintain these copies separately. That is, you'll waste some memory but the plugins and the loaded drivers should not interfere. Would rsyslog be suitable to run such a test, e.g. by loading the output plugin and another (maybe renamed) copy of the same plugin? This is an interesting problem also for other projects which use a plugin system and libdbi. A second question is on the status of the Ingres/mSQL and Oracle drivers. I hope it is OK to post here (it's a one-timer and I'd like to save me another mailing list subscription). Unfortunately there is only rare and irregular feedback on the non-core drivers. However, as insert statements are a prerequisite to do anything useful with a driver, I'd suspect that these should work ok. As for the database engines you mentioned, Ingres is the one that was added last. I assume it supports basic functionality. Oracle has been around a little longer, and there have been some bug reports and patches in the past, so I'd also say it is going to work. I can't recall any feedback about mSQL though, and I'm not sure if anyone on this list is currently using it. As a rule of thumb you may want to steer your users towards the core drivers (firebird, mysql, pgsql, sqlite, sqlite3) and leave the other drivers as an option that will require some end-user testing. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] Feedback and Questions [resend]
It just appears to me that we must have MSSQL in our lab. I'll see that I get some machine next week and try the make check. Will post results, but probably not before mid-week. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Hoenicka Sent: Friday, February 15, 2008 6:53 PM To: libdbi-users@lists.sourceforge.net Subject: Re: [libdbi-users] Feedback and Questions [resend] Rainer Gerhards writes: I just notice that you don't list openTDS as a core driver. Any problems with that one. Or have you just overlooked it? I probably have an actual use case to run it against Sybase soon. core currently means that I can test it on one of my boxen :-) I do not have the means to test or modify the remaining drivers, and there were no volunteers lately that would run a make check using these drivers to turn them into core drivers. There are no known issues with the FreeTDS driver at this time, but I hesitate to include it into the list of actively supported drivers if there is no feedback. If you can run make check with the FreeTDS driver, or convince someone to do so, I'd greatly appreciate to see the results. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] Feedback and Questions [resend]
Markus, I had a somewhat deeper look at dbi_main now. I think four or five functions would need to be changed in the way you propose. However, as this is an interface change, the previous functions would need to remain as is (including the plugin problem). While I looked at the code, I think a few mutex lock/unlock calls would also make it thread-safe. That is not a big issue for me, as rsyslog allows plugins to run on a single thread, but it may be a benefit for other situations. If you like, I can try to apply a number of changes and provide a patch file for your review. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Hoenicka Sent: Friday, February 15, 2008 7:00 PM To: libdbi-users@lists.sourceforge.net Subject: Re: [libdbi-users] Feedback and Questions [resend] Rainer Gerhards writes: In any case, I suggest that a second call of dbi_initialize() inside the same instance should return an error state - sounds better than unpredictable behavior. Making it multi-init safe could IMHO easily be done by using one additional handle. I can't claim to be an expert at these issues, but I imagine that moving the sentinel of the driver list into the application linked against libdbi instead of implementing it as a static global variable might resolve this problem. dbi_initialize would then look somewhat like: dbi_driver_t* dbi_initialize(const char *driverdir, int* numdrivers); (dbi_driver_t may not be user-visible at this time, but you get the idea). I'll be happy to consider this change if it helps to make libdbi plugin-safe. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
