RE: Wanted: MySQL++ Project Maintainer

[Ian Quick]

And I have to agree with both yigong and Warren. I've only recently started 
using mysql, and while I find the database good (and fast) the INTERFACE 
has problems riddled through it... I've already had to started fix bugs in 
mysql++, and every version of mylibsql.dll (under windows) since 3.23 won't 
interface with the borland compilers due to some 'microsoft' interface 
assumptions - instead of leaving it as a generic dll that could be used by 
anything.. Then I started finding bugs in the odbc driver..

All this in only three weeks of use...

I emailed the webmaster (@mysql.com) that we need a FORUM for C++ etc 
issues, instead of this mailing list (which is pretty cumbersome) ie -

 > First thing I looked for was a forum, and you have obviously put one up
 > recently to replace the mailing lists (I HATE mailing lists..). Could you
 > accelerate it along a bit and make groups for everything you run lists for?
 > Even if you don't preload them with archived lists, we could all start
 > using them from now instead of the lists.. (I in particular want a MySQL++
 > one!).

To which I got this response -

 >We are working on rolling out additional forums to supplement the
 >mailing lists. A forum for C++ users will be available soon.

To which I responded

 >How soon? I know it will only take you a few minutes (at the most) to do 
as I run a few of forums.. :-)

which, to date, I haven't got a reply to.

The core problem is that IT DOESN'T MATTER HOW GOOD THE DATABASE IS IF YOU 
CAN'T ACCESS IT RELIABLY!

Given the commercial nature of the mysql project (those license fees must 
be adding up by now) surely a bit more effort could go into the interface 
code, even if it's just coordinating what other people are fixing?

What does everyone think? One option is that I (or someone else) set up a 
mysql developers web site, with forums and copies of peoples code - it 
wouldn't be 'official' but might mean we are more easily see bugs that 
other people have fixed, and could do things a bit faster than the official 
site.  Or is something like that out there and I haven't found it?

Or do we wait for them to do something??

Thoughts anyone?

Ian

At 01:09 AM 10/08/2004, you wrote:
>I agree with Warren. If work load or company priority make the current
>maintainer cannot keep the package as updated as needed, we should have
>a new maintainer for mysql++.
>
>I have installed and used dozens of public domain packages. This is the
>worst maintained one. Its current status will turn possible users away
>which will hurt the future of mysql++ in the end.
>
>Warren, thanks a lot for your effort and please keep your patch alive!
>
>yigong
>
>-----Original Message-----
>From: Warren Young [mailto:warren@stripped]
>Sent: Saturday, August 07, 2004 12:54 AM
>To: MySQL++ Mailing List
>Subject: Wanted: MySQL++ Project Maintainer
>
>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.
>
>         http://tangentsoft.net/mysql++/omnibus-gcc-3.3.patch.gz
>
>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 custom.pl 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
>custom.pl 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
>WHY IT'S A GOOD IDEA TO RELEASE NEW VERSIONS FREQUENTLY.  Evidently the
>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 mysql.com 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
>project.
>
>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.
>
>--
>MySQL++ Mailing List
>For list archives: http://lists.mysql.com/plusplus
>To unsubscribe:
>http://lists.mysql.com/plusplus?unsub=1
>
>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>
>--
>MySQL++ Mailing List
>For list archives: http://lists.mysql.com/plusplus
>To 
>unsubscribe:    http://lists.mysql.com/plusplus?unsub=1