MySQL Lists are EOL. Please join:

List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:August 7 2004 4:53am
Subject:Wanted: MySQL++ Project Maintainer
View as plain text  
When I started using MySQL++, the current version was 1.7.9.  Version
1.7.9 was nearly two years old at that point.  It's now a year and a
half since I started, and the current release is still 1.7.9.

A year and a half ago, I submitted patches to fix problems with MySQL++.
   Instead of being applied to the sources and a new version released,
that patch was simply added to the MySQL++ page.  Several other users
have also released patches, which have been given the same treatment.
This hodgepodge of patches is confusing and not all of the patches give
a fully functional copy of MySQL++.  Worse, the patches are growing: A
recent patch has over 1700 lines of changes.  In any active development
project, that much change would be sufficient grounds for a new release.

	"Release early. Release often." -- Eric S. Raymond, _The
		Cathedral and the Bazaar_

I've been patient.  I've kept my development box running Red Hat 9 --
the last version to come with GCC 3.2 -- because of the incomplete GCC
3.3 support in MySQL++.  I've waited for a year and a half for a new
release incorporating all the user-contributed patches.

This project would be completely stagnant if it weren't for those
patches.  Sinisa, I haven't seen you doing any maintaining, only tech
support by answering questions on this list.  That's fine, tech support
is a useful function.  I just wish you'd give up the title "maintainer"
if you don't intend on releasing any new software.  We need new software.

I'm not complaining without a plan.  I've made an omnibus patch
against 1.7.9 that lets my code build on Fedora Core 2 with GCC 3.3.3.
This patched MySQL++ also builds under GCC 3.2.2 on Red Hat Linux 9, and
under GCC 3.0.4 on Red Hat Linux 7.2, but I didn't test it fully on
those two.  It won't build under GCC 2.96, due to insufficient Standard
C++ support.  It probably wouldn't be hard to fix this, perhaps with an
autoconf check, if one cared to.

I had to host the patch on my web site, because the mailing list 
software rejected it as too big!  You know something's wrong with a 
project when a patch must be 24KB, gzipped.

The first fix I proposed six months ago; it required a judgement call
from Sinisa, but I didn't hear back about it.  The problem is that
MysqlRow has four overloads for operator[], and all four types can be
assigned an integer.  This means that if you say row[0], the compiler
can't figure out which of the four types to convert the 0 to, so it
gives an error.  I've removed all but the size_type overload, and it
fixes the problem.  This means you lose the ability to index a MysqlRow
object with a string.  That's inefficient anyway, so I don't mind losing
the feature.  In the attached patch, I include a lookup_by_name()
function to replace this functionality for those that really need it.
The examples are patched to use this where necessary.

The next part of the patch is also to fix an operator overloading mess.
   Here, removing the extra overloads isn't practical.  Instead, you have
to change line 222 of to this:

          $popul .= "    s->I$j = (T$j)row[ O$j ];";

This forces each of the row assignments to be cast to the proper type,
cluing the compiler in to the proper conversion.

Yet another necessary patch is changing the declaration of _table in to const char*.  I've posted before about this, too.

Before I made the patch, I tried making all of the above changes to 
1.7.9 plus the GCC 3.3 patch on the MySQL++ web page.  All of the 
MySQL++ examples will compile, but an old bug that was patched
before crops up in my own code:

> cbms.cpp:133: error: ISO C++ says that `std::basic_ostream<char, _Traits>&
>    std::operator<<(std::basic_ostream<char, _Traits>&, const char*)
> [with 
>    _Traits = std::char_traits<char>]' and `SQLQuery&
> operator<<(SQLQuery&, 
>    const mysql_ColData<const_string>&)' are ambiguous even though the worst
>    conversion for the former is better than the worst conversion for the latter

I don't remember which old patch fixed this, or how, but when I started
from my personal v1.7.9 variant and made the necessary GCC 3.3 fixes
instead of using the official patch, this error didn't happen.  THIS IS
kind person who made the GCC 3.3 patch didn't check all the previous
patches for necessary fixes before releasing their patch.  They
shouldn't have had to.  The fix should have been in the released MySQL++
version long ago.

On top of all that, it seems that there is no obvious way to find
MySQL++ from the new home page.  It's not on the same page as
the links to Connector/J and Connector/ODBC.  So we have a maintainer
whose employer apparently doesn't give him enough time in 3+ years to
make a single release, and the project page gets lost in a redesign and
nobody cares.  To me, that says MySQL, Inc. has lost interest in this

Sinisa, I've given you a year and a half to show some evidence that
you're going to maintain this project.  I've used up all my patience.
Maintain MySQL++ or I'll maintain it myself.
Wanted: MySQL++ Project MaintainerWarren Young7 Aug
RE: Wanted: MySQL++ Project MaintainerYigong Liu9 Aug
  • RE: Wanted: MySQL++ Project MaintainerIan Quick10 Aug
    • Re: Wanted: MySQL++ Project MaintainerWarren Young11 Aug
      • Re: Wanted: MySQL++ Project MaintainerIan Quick11 Aug