Actually, that code is on my list. However, since there is such a hue and cry over the new driver, I have refrained from putting into master, since that would "freeze" the new driver in place.
Although I'm a proponent of forward motion, we MAY have to roll back the driver and migration change. I really want to avoid that, but until that issue is resolved, I just can't commit any code that builds on it. Melanie Alex Ra wrote: > DC> As far as I understand it, the new driver was added because it > DC> supports stored procedures [better?]; stored procedures will allow > DC> us to speed up some things. But 0.7 still doesn't have any stored > DC> procedures, so the new capabilities are mute. > > > Hello Diva, > > It was me who put the updated MySql driver into the project, so I'm > the one to kick for the mess. > > The reasons were: > > (a) Yes, the ability to *define* multi-statement stored procs. MySQL has > a rather hairy way to switch DELIMITER while defining an SP, so > defining anything with a ';' inside was either impossible or very tricky > with the previous driver. > > You are also correct that stored procs are NOT used currently, however > they can be used to provide "fast" tracking of asset access times, > which, as I understand, is required for cleaning up unused assets and > preventing the database from growing infinitely. The relevant code is > ready, tested and described by me somewhere on Mantis, with a link to > github, but I don't think anybody has bothered to review / merge it > (yet). > > The last time I looked, the access tracking functionality was > commented out in the asset store code, because sending an UPDATE after > each asset fetch just kills the performance (like 10 times slower). > The solution based on stored procs has a performance penalty of about > 10-15%. > > I can re-post the link to Mantis where this approach is described, if > anybody is interested. > > (b) the less important reason is just to keep up with the most recent > versions of the driver. > > Updating the driver also involved some changes in the stores to > correctly convert between values returned/accepted by the driver and > UUIDs in the code. The reason is that the new driver implicitly > converts CHAR(36), returning it as Guid (rather than a string). With > the "Old Guids" config var, the driver would instead convert > BINARY(16) to Guid. > > With the new driver and the corresponding code changes in place, the > "Old Guids" config var should NOT be used. > > > Best regards, > > Alex > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
