On Mon, Jun 13, 2005 at 02:01:43PM -0600, Warren Young wrote:
> 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.
Go right ahead, I have other projects that are pressing right now.
I'll make good use of the mailing list to coordinate effort.
> > - 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,
Sounds good. I'll take that as project #1 when I get time.
> > - 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 have no problem with that. I haven't even looked at it closely enough
to design anything yet, and fully expect that things will be cleaned up
when I get to it. I hope to help clean things up first, so that when
database-independence is added, hopefully there won't be a lot of
maintenance to keep up with the main tree.
One idea that pops into my mind would be a higher level API class, like
your driver idea, and then when the user wishes to select the database
to use, it would be something like:
> 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.
I agree. My database-independence-hinted code will be separate until it
works. Whether that's on a separate branch or just a tarball on my
website doesn't matter to me.
> Naming issues are going to be a problem if you pursue this. namespace
> mysqlpp, libmysqlpp, Gna project mysqlpp...
We can worry about that once something is working. :-)
> > 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?
I agree a driver mechanism seems pretty clean as well. With templates,
perhaps it is possible to get away with only specifying the driver in
one spot. Don't know until I try it.
If I find I need a hierarchy later, I'll have technical arguments to
back it up, and you can talk me out of it then. :-) I'm always open to
better design ideas. Right now I have no working code.