MySQL Lists are EOL. Please join:

List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:June 13 2005 8:01pm
Subject:Re: v2.0 release plan
View as plain text  
Chris Frey wrote:

> Should make
> a neat todo list when I have some spare hacking time.

Please let me know which ones you plan on tackling, and I'll stay away 
from those areas.  Personally, I'm considering starting with the 
exception handling stuff first.

> 	- performance... recent posts to the list have exposed some possible
> 		areas where the library could be tuned.  I'm big on making
> 		use of small hardware, so performance is another key interest

Can I mark you as the responsible party for the Row optimization stuff, 

> 	- database independence... yes, this dream is still alive. :-)

If so, then we'd better do it a different way than it's currently being 

I really dislike the way inheritance is being used to keep these options 
open.  To add a new database server type using the existing scheme, 
you'd have to duplicate a large part of the inheritance hierarchy.  And 
even then, you're still not going to get a working library.  manip.h has 
always depended on the MySQL C API, for instance, yet there's no 
inheritance tree there to make it database independent.  And how could 
it be any other way?  You can't go instantiating new manipulators for 
each database type...

I'd much rather see some sort of interface vs. driver separation, where 
MySQL C API code is separated out into a single driver class, and every 
piece of the library that needs to use it calls it through a generic 
interface.  I seem to recall that this is how Perl's DBI works. 
Probably things like Java's JDBC could also be mined for ideas.

Point being, I still plan on removing all the class names having "mysql" 
in them.  If you later want to separate out a driver layer, you can 
still do that in the new hierarchy.

Above all, I see no point in having even the hint of database 
independence in MySQL++ until at least two database server types are 
supported.  One should never have unused extensibility mechanisms; they 
just become baggage.  One should refactor existing nonextensible 
mechanisms into extensibility, so that you always get exactly the 
interface you need right now, not the one you think you will need someday.

Naming issues are going to be a problem if you pursue this.  namespace 
mysqlpp, libmysqlpp, Gna project mysqlpp...

> 		I don't think this is of much general interest, 

Oh, I don't know.  It'd be nice to have the option to swap out backends, 
just so you'd _know_ how such changes affect one's program.  Even if you 
come back to MySQL, it's nice to have the option.  But can we agree that 
a driver paradigm makes more sense than the current class hierarchy?
v2.0 release planWarren Young11 Jun
  • Re: v2.0 release planChris Frey11 Jun
    • Re: v2.0 release planWarren Young13 Jun
      • Re: v2.0 release planChris Frey14 Jun
        • Re: v2.0 release planWarren Young14 Jun
Re: v2.0 release planWarren Young13 Jun