libdbi-devel — Discussion about development of the core library and DBD interface

[libdbi-devel] libdbi-0.8.2, libdbi-drivers 0.8.2: ready for prime time?

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

Hi all,

as previously announced here I've checked in a couple of minor changes that make
the CVS versions of both libdbi and libdbi-drivers ready for release. All I need
to move on is some feedback from platforms that I can't test. I ran a few tests
on FreeBSD and on Windows XP/Cygwin which showed no regressions. Could anyone
else please confirm that the current CVS versions work ok on major platforms
(Linux, OSX, Solaris, other *BSDs)? I'd like to get this release off my desk.

regards,
Markus

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

[libdbi-devel] Subversion?

[Toby T. <to...@sm...>]

On 15-Feb-07, at 11:02 AM, Markus Hoenicka wrote:

> Toby Thain <to...@sm...> was heard to say:
>
>>> While we're at it: how do other developers and users feel about
>>> moving libdbi
>>> development to subversion? Is it worth the hassle?
>>
>>
>> Assuming I'm included in "other": My vote is yes, I'd feel more
>> comfortable with Svn.
>>
>
> As you brought up the issue, I was assuming you'd vote for  
> Subversion anyway,
> but thanks for clarifying your vote again.


On the other hand, I wouldn't vote for "change for the sake of  
change". :)

If there's no identifiable benefit apart from warm fuzzies then I'd  
stick with CVS. Proper tagging is one of few immediate benefits I can  
think of (although renaming and atomic commits are nice to have).

--Toby

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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

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

Toby Thain <to...@sm...> was heard to say:

> > While we're at it: how do other developers and users feel about
> > moving libdbi
> > development to subversion? Is it worth the hassle?
>
>
> Assuming I'm included in "other": My vote is yes, I'd feel more
> comfortable with Svn.
>

As you brought up the issue, I was assuming you'd vote for Subversion anyway,
but thanks for clarifying your vote again.

regards,
Markus

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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Toby T. <to...@sm...>]

On 14-Feb-07, at 11:01 AM, Markus Hoenicka wrote:

> Mike Rylander <mry...@gm...> was heard to say:
>
> ...
>
>> I've been using the Postgres driver against an 8.2 database in
>> testing, and that seems to work just fine.
>>
>
> That's good. I was more afraid that MySQL 5.0 may cause trouble.  
> Has anyone
> experience with that?

Yes, I committed support for new types some time ago, and the driver  
in general works fine.

--Toby


>
> regards,
> Markus
>
> -- 
> Markus Hoenicka
> mar...@ca...
> (Spam-protected email: replace the quadrupeds with "mhoenicka")
> http://www.mhoenicka.de
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Toby T. <to...@sm...>]

On 12-Feb-07, at 3:38 AM, Markus Hoenicka wrote:

> Toby Thain <to...@sm...> was heard to say:
>
>> I wish Sourceforge would deprecate tarballs entirely and just use Svn
>> tags. It seems (from another project I'm on, at least) that the
>> tarball is always woefully out of date.
>>
>> My advice - go ahead and make a new release.
>>
>
> Well, we'd have to move to subversion first in order to make use of  
> SVN tags.
>
> I'm afraid that "releasing" SVN tags instead of tarballs will deter  
> end-users
> who just need to satisfy some application dependency. A tarball is  
> something
> familiar to non-technical Unix/Linux users, whereas subversion is  
> not. Package
> maintainers are also used to build from tarball releases. Besides,  
> if I find
> the time to bless a subversion revision with a stable tag, most of  
> the work is
> done anyway. I can just as well build the tarball and upload it.  
> This takes
> just another cup of coffee's amount of time.

Mostly agreed. The other project's problem might be that the process  
of preparing the tarball is not documented and is done by one guy;  
also there is a trickle of commits, so somebody has to decide when a  
release is appropriate. The last tarball happened to be made at a  
very bad time (and was not updated yet), so this decision process  
failed us. Infrequent tarballs mean that, as I said, they're  
ridiculously out of date with respect to trunk. (libdbi seems more in  
"maintenance" than new development or frantic bugfixing, so it's not  
really the same case as that project.)

I stopped using tarballs in my own projects some time ago, it was  
only a source of problems.

> While we're at it: how do other developers and users feel about  
> moving libdbi
> development to subversion? Is it worth the hassle?


Assuming I'm included in "other": My vote is yes, I'd feel more  
comfortable with Svn.

In answer to Claudiu:

> Why don't you release SVN tags and make tarballs, also? It's a good  
> idea
> to have a tag in SVN... ie: if you want to make a quick diff from the
> previous release version to trunk?

  Tag *must* be done when a tarball is made, I don't see that as  
optional.

--Toby

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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Christian M. S. <cm...@ce...>]

Hi all,


I would also like to start by thanking Markus for taking over as  
maintainer for this project, and continue the work.
Thanks a lot Markus, I know i could have helped you a lot more.



On 12 Feb 2007, at 12:49, Markus Hoenicka wrote:
[...]

>
> It is nice to see such a high-profile project use libdbi successfully!
>


Although it not a public project the company I work for (Cention) is  
using libdbi (although slightly tweaked to get access to some extra  
functions for our search engine) in our main product Cention Contact  
Center.

This software have live installation all over the world, including  
America, Asia and Europe. Some of Scandinavia's largest call center  
are running this application.

So i would say the  libdbi software is very much stable and have been  
ready for prime time for a very long time.

Also the programming language Ferite[1] is getting a larger user base  
everyday and the dbi module for that language is written as layer on  
top of libdbi.


>> Is it time for 0.8.2?
>>


Most defiantly, we are using CVS from about a couple of months in our  
production code base.


+1 to release a new version.


I also want to add some code to use prepared staements and cursors,  
but that will have to wait.
I would be very happy to see a new stable release to see the day light.




Best Regards,


Christian Stamgren


[1] www.ferite.org

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

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

Mike Rylander writes:
 > It's actually the libdbi-drivers Makefile that needs patching, and
 > it's currently specific to linux builds for us.  Mingw and Cygwin may
 > not mind dl-loading-a-dl like linux seems to.  It's documented here:
 > 
 >   http://open-ils.org/dokuwiki/doku.php?id=libdbi
 > 
 > and amounts to adding -ldbi to the LDFLAGS var for the drivers.
 > 

I've comitted a couple of changes to the cvs repositories of libdbi
and libdbi-drivers:

- removed the leftover fprintf debug call from libdbi/src/dbd_helper.c

- added a --enable-libdbi switch to libdbi-drivers/configure.in. If
  you use this switch, all drivers will be linked against
  libdbi. Please suggest a better name for this option if you can come
  up with one. Making this configurable does not require us to run
  tests on all available platforms whether or not the drivers linked
  against libdbi fail.

- added a --with-dbi-libdir option to set the library path
  appropriately if libdbi.so/libdbi.a should be installed in an odd
  place

- fixed a typo in libdbi-drivers/configure.in which may be responsible
  that the docs get built on some platforms although the
  --disable-docs switch was used

I didn't check in the sqlite3 concurrency code yet as I'll have to run
some more tests before releasing it into the wild. Please give the
current cvs version a try and let me know if it works out of the box
for your setup. I'll try to come up with some additions to the
documentation to describe the new options and the possible setups.

regards,
Markus

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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Mike R. <mry...@gm...>]

On 2/14/07, Markus Hoenicka <mar...@mh...> wrote:
> Mike Rylander <mry...@gm...> was heard to say:
>
>
> > hmmm... The libtool interface version number is about compatibility,
> > where as the release number is about human-understandable "freshness".
> >  These are orthogonal concepts, though the former does deserve
> > attention.  It seems to me that the LIB_CURRENT and LIB_AGE should
> > just both be 0, since there is no previously versioned interface.
> > Then LIB_CURRENT just gets bumped when new functions are added, and
> > LIB_AGE gets bumped as old functions are changed, deprecated or
> > removed.  Trying to make the version number match the interface number
> > seem both counter productive (a new interface version for each
> > release?) and against libtool best practices, no? ... I may be
> > misunderstanding the proposal, though.
> >
>
> Maybe *I* am all dense about the libtool versioning stuff, but I see it like
> this: LIB_AGE is for recording the backwards-compatibility and thus is not
> relevant for the version number. All we have to consider is LIB_CURRENT (the
> number of the interface) and LIB_REVISION (loosely, the number of released
> source code changes that did not alter the interface). libdbi version numbers
> were picked rather randomly at the beginning, but as we had the drivers in a
> separate project, we wanted to avoid having, say, libdbi-drivers 8.3 depend on
> libdbi 7.5. We therefore decided to have all 0.8.x releases of libdbi work with
> all 0.8.x releases of libdbi-drivers and so on. While this schema does not
> strictly prevent changes to the application vs. libdbi interface (it prevents
> changes to the libdbi vs. libdbi-drivers interface), it is unlikely to change
> one interface without changing the other. Therefore we currently have "0.8" as
> a rather randomly picked interface number and "1" as the revision number.

Sorry, I should have investigated much more closely before speaking...
I was basing all that on the SF bug discussion, which was more about
the abstract use of the LIB_* stuff, I believe -- or at least pre-use.
 If there's already a procedure in place then I don't want to suggest
we change it.

>
> If we follow your request to release the current CVS code (more on that below),
> libtool would require no change of LIB_CURRENT, but LIB_REVISION would need to
> be bumped up. This is just what happens if we name the new release 0.8.2 (the
> interface remains at "0.8", the revision moves to "2".
>
> What I suggested in the discussion of the feature request back then is to make a
> clean start with the version and interface numbers next time we need to change
> the interface. The interface number, and thus the major version, should be "1",
> and the revision (= minor version) should start at "0". This is equivalent to
> stating that we'll bump up the major version whenever the interface changes,
> and the minor version whenever we add features that do not require a change of
> the interface. If we agree on that, there is no reason not to use the libtool
> numbers as the version number (LIB_CURRENT.LIB_REVISION). It is one set of
> numbers less that need the attention of the developers.
>

Sure, and for a library package that definitely makes sense.  In fact
the more I think about it the more sense it makes... :)

[sinp]

>
> > On a related note, we should also consider adding the "link libdbi
> > into drivers" patch that's been floating around into CVS.  Our project
> > requires that we do this, as it uses the
> >
> >   Parent => dl_open(app-logic) => dl_open(libdbi) => dl_open(libdbi-driver)
> >
> > pattern.  When libdbi goes to load the driver it can't due to missing
> > symbols that the driver requires in the loading binary.  Linking
> > libdbi into the drivers fixes this, it's a one line change in the
> > Makefile, and it does not break the more traditional setup.  In fact,
> > this would help with the above mentioned libdbi <-> driver interface
> > checks.
> >
> > Note that any apache module that attempts to use libdbi will also
> > suffer from this.
> >
>
> I recall this discussion, but I didn't have enough time to look into this. We'll
> have to test whether the traditional setup is not affected by this on any
> platform supported so far. I'm especially concerned about Cygwin and Mingw. To
> speed up things, do you have a link to that patch handy?
>

It's actually the libdbi-drivers Makefile that needs patching, and
it's currently specific to linux builds for us.  Mingw and Cygwin may
not mind dl-loading-a-dl like linux seems to.  It's documented here:

  http://open-ils.org/dokuwiki/doku.php?id=libdbi

and amounts to adding -ldbi to the LDFLAGS var for the drivers.

> > Having said all everything above, I'd personally prefer to see a new
> > version out right now with the current code.  It is tested and stable,
[snip]
> >
>
> I can feel your pain :-( I'm personally inclined to follow your suggestion and
> use the current CVS version plus the "link libdbi into drivers" patch (if it
> does not break things) to release 0.8.2 in a matter of days. I'd suggest to put
> the other changes on the back burner for another month or two and take our time
> to do it right.
>

+1

Thanks, Markus!

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


-- 
Mike Rylander
mry...@gm...
GPLS -- PINES Development
Database Developer
http://open-ils.org

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

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

Mike Rylander <mry...@gm...> was heard to say:


> hmmm... The libtool interface version number is about compatibility,
> where as the release number is about human-understandable "freshness".
>  These are orthogonal concepts, though the former does deserve
> attention.  It seems to me that the LIB_CURRENT and LIB_AGE should
> just both be 0, since there is no previously versioned interface.
> Then LIB_CURRENT just gets bumped when new functions are added, and
> LIB_AGE gets bumped as old functions are changed, deprecated or
> removed.  Trying to make the version number match the interface number
> seem both counter productive (a new interface version for each
> release?) and against libtool best practices, no? ... I may be
> misunderstanding the proposal, though.
>

Maybe *I* am all dense about the libtool versioning stuff, but I see it like
this: LIB_AGE is for recording the backwards-compatibility and thus is not
relevant for the version number. All we have to consider is LIB_CURRENT (the
number of the interface) and LIB_REVISION (loosely, the number of released
source code changes that did not alter the interface). libdbi version numbers
were picked rather randomly at the beginning, but as we had the drivers in a
separate project, we wanted to avoid having, say, libdbi-drivers 8.3 depend on
libdbi 7.5. We therefore decided to have all 0.8.x releases of libdbi work with
all 0.8.x releases of libdbi-drivers and so on. While this schema does not
strictly prevent changes to the application vs. libdbi interface (it prevents
changes to the libdbi vs. libdbi-drivers interface), it is unlikely to change
one interface without changing the other. Therefore we currently have "0.8" as
a rather randomly picked interface number and "1" as the revision number.

If we follow your request to release the current CVS code (more on that below),
libtool would require no change of LIB_CURRENT, but LIB_REVISION would need to
be bumped up. This is just what happens if we name the new release 0.8.2 (the
interface remains at "0.8", the revision moves to "2".

What I suggested in the discussion of the feature request back then is to make a
clean start with the version and interface numbers next time we need to change
the interface. The interface number, and thus the major version, should be "1",
and the revision (= minor version) should start at "0". This is equivalent to
stating that we'll bump up the major version whenever the interface changes,
and the minor version whenever we add features that do not require a change of
the interface. If we agree on that, there is no reason not to use the libtool
numbers as the version number (LIB_CURRENT.LIB_REVISION). It is one set of
numbers less that need the attention of the developers.


> That actually seems fairly trivial for all types except
> DBI_TYPE_BINARY -- that might require base64 encoding or the like.
> I'll look into doing this.
>

Much appreciated. I also don't see major obstacles, except that we may need a
couple of configure tests for any non-standard conversion functions.

> I've been using the Postgres driver against an 8.2 database in
> testing, and that seems to work just fine.
>

That's good. I was more afraid that MySQL 5.0 may cause trouble. Has anyone
experience with that?

> On a related note, we should also consider adding the "link libdbi
> into drivers" patch that's been floating around into CVS.  Our project
> requires that we do this, as it uses the
>
>   Parent => dl_open(app-logic) => dl_open(libdbi) => dl_open(libdbi-driver)
>
> pattern.  When libdbi goes to load the driver it can't due to missing
> symbols that the driver requires in the loading binary.  Linking
> libdbi into the drivers fixes this, it's a one line change in the
> Makefile, and it does not break the more traditional setup.  In fact,
> this would help with the above mentioned libdbi <-> driver interface
> checks.
>
> Note that any apache module that attempts to use libdbi will also
> suffer from this.
>

I recall this discussion, but I didn't have enough time to look into this. We'll
have to test whether the traditional setup is not affected by this on any
platform supported so far. I'm especially concerned about Cygwin and Mingw. To
speed up things, do you have a link to that patch handy?

> Having said all everything above, I'd personally prefer to see a new
> version out right now with the current code.  It is tested and stable,
> and does exactly what I need (other than the driver-libdbi linking
> issue, but that's separate).  There seems to have been a descent
> amount of code added since 0.8.1 was released, and now that this
> codebase is in use in a large production project (it's been tested
> stable, etc) my immediate concern is stamping the code as "good" and
> being able to point others at a tarball to say "that is tested and
> works."  As it stands, I get funny looks (or worse, no second look at
> all) when I say, "Grab libdbi from CVS.  Yes, it's stable and safe,
> it's just not wrapped up in a download yet."  So ... I'm sure you can
> understand my frustration ...
>

I can feel your pain :-( I'm personally inclined to follow your suggestion and
use the current CVS version plus the "link libdbi into drivers" patch (if it
does not break things) to release 0.8.2 in a matter of days. I'd suggest to put
the other changes on the back burner for another month or two and take our time
to do it right.

regards,
Markus

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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Mike R. <mry...@gm...>]

On 2/12/07, Markus Hoenicka <mar...@mh...> wrote:
> Mike Rylander <mry...@gm...> was heard to say:
>
> > Continuing this long-dormant thread, I want to thank the libdbi core
> > team for the help and support in getting basic ISO timezone support
> > into the code base.  It has helped the Evergreen[1] project immensely,
> > as we wouldn't have a fast and stable database connector without it.
> >
>
> It is nice to see such a high-profile project use libdbi successfully!
>
> > Is it time for 0.8.2?
> >
>
> libdbi has a history of being developed in batch mode. Development usually is
> dormant as long as no one complains about bugs or missing features. Maybe it is

Entirely understandable, especially given that current stability of the code.

> time again for a wake-up call to the hibernating developers to collect all
> issues which should be addressed in an upcoming new release. From my POV, the
> following things come to mind (they have been requested previously, but I
> couldn't find the mails right away as I'm away from my development box):
>
> - change the release version numbers to the library interface numbers. The issue
> has been discussed before
> (http://sourceforge.net/tracker/index.php?func=detail&aid=1578577&group_id=65979&atid=512948).
> This change will allow better version checks by the runtime linker and thus will
> avoid frustrations when using applications built against an incompatible libdbi
> version.
>

hmmm... The libtool interface version number is about compatibility,
where as the release number is about human-understandable "freshness".
 These are orthogonal concepts, though the former does deserve
attention.  It seems to me that the LIB_CURRENT and LIB_AGE should
just both be 0, since there is no previously versioned interface.
Then LIB_CURRENT just gets bumped when new functions are added, and
LIB_AGE gets bumped as old functions are changed, deprecated or
removed.  Trying to make the version number match the interface number
seem both counter productive (a new interface version for each
release?) and against libtool best practices, no? ... I may be
misunderstanding the proposal, though.

> - add a "late binding" interface to libdbi. Currently you have either to know in
> advance which type a particular query is going to return, or you have to add
> type checks after each query in order to find out. A "late binding" interface
> would allow to request e.g. a string or an integer from any type of field, with
> libdbi performing all required conversions.
>

That actually seems fairly trivial for all types except
DBI_TYPE_BINARY -- that might require base64 encoding or the like.
I'll look into doing this.

> - the drivers should be overhauled too where necessary. I've fiddled with some
> experimental code to improve concurrent accesses with sqlite3. Also, we should
> check at least the MySQL and PostgreSQL drivers with the latest versions of
> these database engines to work out any compatibility issues.
>

I've been using the Postgres driver against an 8.2 database in
testing, and that seems to work just fine.

On a related note, we should also consider adding the "link libdbi
into drivers" patch that's been floating around into CVS.  Our project
requires that we do this, as it uses the

  Parent => dl_open(app-logic) => dl_open(libdbi) => dl_open(libdbi-driver)

pattern.  When libdbi goes to load the driver it can't due to missing
symbols that the driver requires in the loading binary.  Linking
libdbi into the drivers fixes this, it's a one line change in the
Makefile, and it does not break the more traditional setup.  In fact,
this would help with the above mentioned libdbi <-> driver interface
checks.

Note that any apache module that attempts to use libdbi will also
suffer from this.

> The above issues are just suggestions. If anything else seems worth to be
> included in the next release, feel free to add your favourites.
>

Having said all everything above, I'd personally prefer to see a new
version out right now with the current code.  It is tested and stable,
and does exactly what I need (other than the driver-libdbi linking
issue, but that's separate).  There seems to have been a descent
amount of code added since 0.8.1 was released, and now that this
codebase is in use in a large production project (it's been tested
stable, etc) my immediate concern is stamping the code as "good" and
being able to point others at a tarball to say "that is tested and
works."  As it stands, I get funny looks (or worse, no second look at
all) when I say, "Grab libdbi from CVS.  Yes, it's stable and safe,
it's just not wrapped up in a download yet."  So ... I'm sure you can
understand my frustration ...

Anyway, thanks again for this awesome package.  It's been a huge help,
and I'll continue to do what I can as time permits to help improve it.

-- 
Mike Rylander
mry...@gm...
GPLS -- PINES Development
Database Developer
http://open-ils.org

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

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

Toby Thain <to...@sm...> was heard to say:

> I wish Sourceforge would deprecate tarballs entirely and just use Svn
> tags. It seems (from another project I'm on, at least) that the
> tarball is always woefully out of date.
>
> My advice - go ahead and make a new release.
>

Well, we'd have to move to subversion first in order to make use of SVN tags.

I'm afraid that "releasing" SVN tags instead of tarballs will deter end-users
who just need to satisfy some application dependency. A tarball is something
familiar to non-technical Unix/Linux users, whereas subversion is not. Package
maintainers are also used to build from tarball releases. Besides, if I find
the time to bless a subversion revision with a stable tag, most of the work is
done anyway. I can just as well build the tarball and upload it. This takes
just another cup of coffee's amount of time.

While we're at it: how do other developers and users feel about moving libdbi
development to subversion? Is it worth the hassle?

regards,
Markus


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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

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

Mike Rylander <mry...@gm...> was heard to say:

> Continuing this long-dormant thread, I want to thank the libdbi core
> team for the help and support in getting basic ISO timezone support
> into the code base.  It has helped the Evergreen[1] project immensely,
> as we wouldn't have a fast and stable database connector without it.
>

It is nice to see such a high-profile project use libdbi successfully!

> Is it time for 0.8.2?
>

libdbi has a history of being developed in batch mode. Development usually is
dormant as long as no one complains about bugs or missing features. Maybe it is
time again for a wake-up call to the hibernating developers to collect all
issues which should be addressed in an upcoming new release. From my POV, the
following things come to mind (they have been requested previously, but I
couldn't find the mails right away as I'm away from my development box):

- change the release version numbers to the library interface numbers. The issue
has been discussed before
(http://sourceforge.net/tracker/index.php?func=detail&aid=1578577&group_id=65979&atid=512948).
This change will allow better version checks by the runtime linker and thus will
avoid frustrations when using applications built against an incompatible libdbi
version.

- add a "late binding" interface to libdbi. Currently you have either to know in
advance which type a particular query is going to return, or you have to add
type checks after each query in order to find out. A "late binding" interface
would allow to request e.g. a string or an integer from any type of field, with
libdbi performing all required conversions.

- the drivers should be overhauled too where necessary. I've fiddled with some
experimental code to improve concurrent accesses with sqlite3. Also, we should
check at least the MySQL and PostgreSQL drivers with the latest versions of
these database engines to work out any compatibility issues.

The above issues are just suggestions. If anything else seems worth to be
included in the next release, feel free to add your favourites.

>
> UPDATE:  While looking at the code I notices that one of my original
> debugging fprintf's managed to hang around.  Attached is a patch that
> comments out that one line, and does nothing else.  It's probably just
> as easy for someone to go in and remove all the fprintf lines,
> commented out or not, since they're not needed at all, AFAICS.  Thanks
> again!

I've noticed that fprintf message too, but it didn't bother me enough to correct
it. I'll do as soon as time permits.

regards,
Markus


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

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Toby T. <to...@sm...>]

On 11-Feb-07, at 9:08 PM, Mike Rylander wrote:

> Continuing this long-dormant thread, I want to thank the libdbi core
> team for the help and support in getting basic ISO timezone support
> into the code base.  It has helped the Evergreen[1] project immensely,
> as we wouldn't have a fast and stable database connector without it.
>
> We are now relying on the code in CVS for our production services at
> PINES[2], and we're getting a good deal of outside interest and test
> implementations.  As such, we're pulling libdbi from CVS when we need
> to build a new server, and we're advising others to do the same.  As
> you can imagine, this is less than optimal for sites that are short on
> time or expertise, and gives a feeling (at least to those uninitiated
> with open source) of bleeding-edge requirements that can turn less
> experimental potential users off.
>
> So, with that, I'd like to see what the general feeling of the
> community would be to releasing a new tarball for the current
> codebase.  As I mentioned, we're currently using this heavily in
> production and we are extremely happy with the performance and
> stability.  I'm not sure if any other projects have adopted or tested
> the current code, but as far as the timezone support goes, it is very
> stable in our use.
>
> Is it time for 0.8.2?


I wish Sourceforge would deprecate tarballs entirely and just use Svn  
tags. It seems (from another project I'm on, at least) that the  
tarball is always woefully out of date.

My advice - go ahead and make a new release.

--Toby

>
> TIA
>
> [1] http://open-ils.org
> [2] http://gapines.org and http://www.georgialibraries.org
>
> UPDATE:  While looking at the code I notices that one of my original
> debugging fprintf's managed to hang around.  Attached is a patch that
> comments out that one line, and does nothing else.  It's probably just
> as easy for someone to go in and remove all the fprintf lines,
> commented out or not, since they're not needed at all, AFAICS.  Thanks
> again!
>
> -- 
> Mike Rylander
> mry...@gm...
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
>
>
> On 5/16/06, Mike Rylander <mry...@gm...> wrote:
>> On 5/16/06, Markus Hoenicka <mar...@mh...> wrote:
>> > Mike Rylander writes:
>> >  > I've attached a patch against my local copy of the new file,  
>> so it
>> >  > should patch CVS with out too much of a fight.  I've added a  
>> little
>> >  > logic to look for a ':' minute separator in the -8:00  
>> format.  It
>> >  > compiles and runs for me, so please give it a whirl and make  
>> sure it
>> >  > passes muster.
>> >  >
>> >
>> > The patch works as advertized. However, I felt the same could be
>> > achieved with less code, and I started to reimplement the timezone
>> > handling by reversing the logic. Checking for a separator first  
>> allows
>> > a cleaner implementation imho. I've checked in the code, a patch
>> > against the pre-timezone dbd_helper.c is attached. Please check
>> > whether the current implementation works ok for your testcases.
>>
>> The patch works perfectly, and the logic is definitely more readable
>> now.  Thanks again!
>>
>> >
>> > regards,
>> > Markus
>> >
>> >
>> >
>> >
>> > --
>> > Markus Hoenicka
>> > mar...@ca...
>> > (Spam-protected email: replace the quadrupeds with "mhoenicka")
>> > http://www.mhoenicka.de
>> >
>> >
>> >
>>
>>
>> --
>> Mike Rylander
>> mry...@gm...
>> GPLS -- PINES Development
>> Database Developer
>> http://open-ils.org
>>
>> <libdbi-fprintf-comment.patch>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
> _________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel

Re: [libdbi-devel] [libdbi-users] driver issues and timezones

[Mike R. <mry...@gm...>]

Continuing this long-dormant thread, I want to thank the libdbi core
team for the help and support in getting basic ISO timezone support
into the code base.  It has helped the Evergreen[1] project immensely,
as we wouldn't have a fast and stable database connector without it.

We are now relying on the code in CVS for our production services at
PINES[2], and we're getting a good deal of outside interest and test
implementations.  As such, we're pulling libdbi from CVS when we need
to build a new server, and we're advising others to do the same.  As
you can imagine, this is less than optimal for sites that are short on
time or expertise, and gives a feeling (at least to those uninitiated
with open source) of bleeding-edge requirements that can turn less
experimental potential users off.

So, with that, I'd like to see what the general feeling of the
community would be to releasing a new tarball for the current
codebase.  As I mentioned, we're currently using this heavily in
production and we are extremely happy with the performance and
stability.  I'm not sure if any other projects have adopted or tested
the current code, but as far as the timezone support goes, it is very
stable in our use.

Is it time for 0.8.2?

TIA

[1] http://open-ils.org
[2] http://gapines.org and http://www.georgialibraries.org

UPDATE:  While looking at the code I notices that one of my original
debugging fprintf's managed to hang around.  Attached is a patch that
comments out that one line, and does nothing else.  It's probably just
as easy for someone to go in and remove all the fprintf lines,
commented out or not, since they're not needed at all, AFAICS.  Thanks
again!

-- 
Mike Rylander
mry...@gm...
GPLS -- PINES Development
Database Developer
http://open-ils.org


On 5/16/06, Mike Rylander <mry...@gm...> wrote:
> On 5/16/06, Markus Hoenicka <mar...@mh...> wrote:
> > Mike Rylander writes:
> >  > I've attached a patch against my local copy of the new file, so it
> >  > should patch CVS with out too much of a fight.  I've added a little
> >  > logic to look for a ':' minute separator in the -8:00 format.  It
> >  > compiles and runs for me, so please give it a whirl and make sure it
> >  > passes muster.
> >  >
> >
> > The patch works as advertized. However, I felt the same could be
> > achieved with less code, and I started to reimplement the timezone
> > handling by reversing the logic. Checking for a separator first allows
> > a cleaner implementation imho. I've checked in the code, a patch
> > against the pre-timezone dbd_helper.c is attached. Please check
> > whether the current implementation works ok for your testcases.
>
> The patch works perfectly, and the logic is definitely more readable
> now.  Thanks again!
>
> >
> > regards,
> > Markus
> >
> >
> >
> >
> > --
> > Markus Hoenicka
> > mar...@ca...
> > (Spam-protected email: replace the quadrupeds with "mhoenicka")
> > http://www.mhoenicka.de
> >
> >
> >
>
>
> --
> Mike Rylander
> mry...@gm...
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
>

[libdbi-devel] [ libdbi-Bugs-1597376 ] using dselect (Debian)

[SourceForge.net <no...@so...>]

Bugs item #1597376, was opened at 2006-11-16 00:54
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://libdbi.sourceforge.net/debian testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454334 package 'libdbd-mysql': field name 'This' must be followed by colon

update available list script returned error exit status 2.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-21 18:04

Message:
Logged In: YES 
user_id=85809
Originator: NO

Fine. Will close the bug report now.

----------------------------------------------------------------------

Comment By: John Beining (jbeining)
Date: 2006-11-18 21:57

Message:
Logged In: YES 
user_id=1646509
Originator: YES

The problem is fixed.
I have tested the new repository (Packages.gz 17-Nov-2006 01:45) by using
'apt-get install' 'dselect' and aptitude'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1597376 ] using dselect (Debian)

[SourceForge.net <no...@so...>]

Bugs item #1597376, was opened at 2006-11-16 00:54
Message generated for change (Comment added) made by jbeining
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://libdbi.sourceforge.net/debian testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454334 package 'libdbd-mysql': field name 'This' must be followed by colon

update available list script returned error exit status 2.

----------------------------------------------------------------------

>Comment By: John Beining (jbeining)
Date: 2006-11-18 21:57

Message:
Logged In: YES 
user_id=1646509
Originator: YES

The problem is fixed.
I have tested the new repository (Packages.gz 17-Nov-2006 01:45) by using
'apt-get install' 'dselect' and aptitude'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1597376 ] using dselect (Debian)

[SourceForge.net <no...@so...>]

Bugs item #1597376, was opened at 2006-11-16 00:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://libdbi.sourceforge.net/debian testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454334 package 'libdbd-mysql': field name 'This' must be followed by colon

update available list script returned error exit status 2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1597376&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577323 ] sqlite error messages being discarded

[SourceForge.net <no...@so...>]

Bugs item #1577323, was opened at 2006-10-14 21:01
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded

Initial Comment:

Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-16 22:27

Message:
Logged In: YES 
user_id=85809

As mentioned by pcmacdon, the bug is better dealt with in
the libdbi-drivers project. For followups please see bug
#1577808.

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-16 05:09

Message:
Logged In: YES 
user_id=190660

BTW:

After the fact, I submitted this same but to the 
libdbi-drivers bug page:

https://sourceforge.net/tracker/?func=detail&atid=512945&aid=1577808&group_id=65979

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-16 05:04

Message:
Logged In: YES 
user_id=190660

It won't.  The problem here is that the sqlite error
message coming back in "errmsg" is never looked at,
and it never gets copied to conn->error_message.

Haven't tried the patch yet, but I think it will work
for the core dump.


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 23:50

Message:
Logged In: YES 
user_id=85809

This is an alternative patch that is supposed to make the
patch for #1577286 unnecessary. The patch is currently only
for SQLite. Could you please check whether this patch fixes
the problems of this bug report and those of #1577286?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577286 ] core dump in dbi_main.c _error_handler()

[SourceForge.net <no...@so...>]

Bugs item #1577286, was opened at 2006-10-14 19:37
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump in dbi_main.c _error_handler()

Initial Comment:
In _error_handler() a free() is performed 
when the new value == old value, in essence
freeing itself.  This is causing random core dumps.

I also added a sanity check before access to
errflag_messages[]..

Attached is a patch.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-16 22:25

Message:
Logged In: YES 
user_id=85809

I've analyzed the situation again, and I still maintain
there is no need to fix dbi_main.c. The situation where new
value == old value, resulting in a NULL assignment, can only
arise if a driver abuses the error message system. This has
unfortunately been the case for the sqlite and sqlite3
drivers. See the discussion for bug #1577808 (reassigned to
libdbi-drivers from #1577323). I'll close this bug as it
appears to be a libdbi-drivers problem.

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-16 05:16

Message:
Logged In: YES 
user_id=190660

Unfortunately, that's no possible.  I didn't even start
working on the #1577323 problem until a couple of hours
after I had found and fixed this core dump problem.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 23:46

Message:
Logged In: YES 
user_id=85809

I've tried to figure out what's wrong here, and I believe
this patch is only required after the patch provided for bug
#1577323 is applied. I've appended an alternative patch for
#1577323. Could you please check whether the problem you
mentioned in this bug report persist after you applied that
patch? Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577286 ] core dump in dbi_main.c _error_handler()

[SourceForge.net <no...@so...>]

Bugs item #1577286, was opened at 2006-10-14 10:37
Message generated for change (Comment added) made by pcmacdon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump in dbi_main.c _error_handler()

Initial Comment:
In _error_handler() a free() is performed 
when the new value == old value, in essence
freeing itself.  This is causing random core dumps.

I also added a sanity check before access to
errflag_messages[]..

Attached is a patch.

----------------------------------------------------------------------

>Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-15 20:16

Message:
Logged In: YES 
user_id=190660

Unfortunately, that's no possible.  I didn't even start
working on the #1577323 problem until a couple of hours
after I had found and fixed this core dump problem.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 14:46

Message:
Logged In: YES 
user_id=85809

I've tried to figure out what's wrong here, and I believe
this patch is only required after the patch provided for bug
#1577323 is applied. I've appended an alternative patch for
#1577323. Could you please check whether the problem you
mentioned in this bug report persist after you applied that
patch? Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577323 ] sqlite error messages being discarded

[SourceForge.net <no...@so...>]

Bugs item #1577323, was opened at 2006-10-14 12:01
Message generated for change (Comment added) made by pcmacdon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded

Initial Comment:

Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .

----------------------------------------------------------------------

>Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-15 20:09

Message:
Logged In: YES 
user_id=190660

BTW:

After the fact, I submitted this same but to the 
libdbi-drivers bug page:

https://sourceforge.net/tracker/?func=detail&atid=512945&aid=1577808&group_id=65979

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-15 20:04

Message:
Logged In: YES 
user_id=190660

It won't.  The problem here is that the sqlite error
message coming back in "errmsg" is never looked at,
and it never gets copied to conn->error_message.

Haven't tried the patch yet, but I think it will work
for the core dump.


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 14:50

Message:
Logged In: YES 
user_id=85809

This is an alternative patch that is supposed to make the
patch for #1577286 unnecessary. The patch is currently only
for SQLite. Could you please check whether this patch fixes
the problems of this bug report and those of #1577286?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577323 ] sqlite error messages being discarded

[SourceForge.net <no...@so...>]

Bugs item #1577323, was opened at 2006-10-14 12:01
Message generated for change (Comment added) made by pcmacdon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded

Initial Comment:

Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .

----------------------------------------------------------------------

>Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-15 20:04

Message:
Logged In: YES 
user_id=190660

It won't.  The problem here is that the sqlite error
message coming back in "errmsg" is never looked at,
and it never gets copied to conn->error_message.

Haven't tried the patch yet, but I think it will work
for the core dump.


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 14:50

Message:
Logged In: YES 
user_id=85809

This is an alternative patch that is supposed to make the
patch for #1577286 unnecessary. The patch is currently only
for SQLite. Could you please check whether this patch fixes
the problems of this bug report and those of #1577286?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577323 ] sqlite error messages being discarded

[SourceForge.net <no...@so...>]

Bugs item #1577323, was opened at 2006-10-14 21:01
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded

Initial Comment:

Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 23:50

Message:
Logged In: YES 
user_id=85809

This is an alternative patch that is supposed to make the
patch for #1577286 unnecessary. The patch is currently only
for SQLite. Could you please check whether this patch fixes
the problems of this bug report and those of #1577286?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577286 ] core dump in dbi_main.c _error_handler()

[SourceForge.net <no...@so...>]

Bugs item #1577286, was opened at 2006-10-14 19:37
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump in dbi_main.c _error_handler()

Initial Comment:
In _error_handler() a free() is performed 
when the new value == old value, in essence
freeing itself.  This is causing random core dumps.

I also added a sanity check before access to
errflag_messages[]..

Attached is a patch.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-15 23:46

Message:
Logged In: YES 
user_id=85809

I've tried to figure out what's wrong here, and I believe
this patch is only required after the patch provided for bug
#1577323 is applied. I've appended an alternative patch for
#1577323. Could you please check whether the problem you
mentioned in this bug report persist after you applied that
patch? Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577286&group_id=23824

[libdbi-devel] [ libdbi-Bugs-1577323 ] sqlite error messages being discarded

[SourceForge.net <no...@so...>]

Bugs item #1577323, was opened at 2006-10-14 12:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded

Initial Comment:

Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=1577323&group_id=23824