How about simply letting sapdb exist completely unaltered along with completely unaltered client liberaries (hopefully on the same licenses as well:) and simply make a new sapdb client that implements the interface of a storage engine.
I don't know anything about the mysql storageengine interface but if it doesn't involve sql (well it probably doesn't) then a higher level interface is needed so the sapdb engine can keep working with highlevel sql and do all of its own planning.
One way to provide this high-level interface and score a major general feature at the same time is to add an extra layer ontop of the currenct mysql sql interface so you could hand it stuff like:
select m.ip, s2.name from mysqlTable m, sapdbTable s1, anotherSabdbTable s2 where m.id=s1.session_id and s1.user_id=s2.user_id
The top layer would then re-write this query into a query that will be passed to the sapdb instance and another one that will be passed to the mysql instance, however the tricky part is knowing what table to get all rows from so this layer needs to keep some statistics about the expected number of rows of each query to select the correct strategy.
This all starts to sound like something that would be better off in a different project to make an distributed transaction controller (or whatever these things are called) that allows the applications to talk to different databases in the same query and make that as invisible as possible.
I realize that this is a huge job, but getting started would be relatively easy if you start by building a system that only allows tables from one database instance in each query and expand the system with multi-database queries later when the two-phase-commit, query distribution and connection pooling framework has been debugged.
I think that this approach would be much better for mysql ab, existing mysql users and existing sapdb users because:
1) mysql ab would have a new product that you could market independantly of DBMSes
2) mysql users who don't care about accessing more than one database don't have to pay the cost of the abstraction.
3) Developers of any component don't need to keep all of sapdb and mysql in their heads to get any work done, sapdb contains tons of really weird code and because the most important bits are pascal porting anything out of it directly is going to be very, very hard.
4) Critical sapdb users can bypass the mysql code and talk directly to the sapdb instance they want to access, just like the old days.
5) New users will be able to use one database connection to run queries in any number of databases and commit changes to all of them with one commit.
In the end I think that this project would be a lot easier to complete than to adapt the very complex and arcane bits of sapdb to mysql and I fear that trying to weld them together might destroy what is good about both.
-- Regards Flemming Frandsen - http://dion.swamp.dk PartyTicket.Net co founder & Yet Another Perl Hacker
_______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
