From: Warren Young Date: June 13 2005 8:01pm Subject: Re: v2.0 release plan List-Archive: http://lists.mysql.com/plusplus/4522 Message-Id: <42ADE627.5070605@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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?