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,
then?
> - database independence... yes, this dream is still alive. :-)
If so, then we'd better do it a different way than it's currently being
handled.
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?
