Stewart Smith wrote: > I'm increasingly developing small plugins to help in testing. They > aren't ever designed for end users (and would circumvent things like > security, could cause stability issues or eat your young). > > What are peoples thoughts on some decent way to hide these from > people? > > I only ever want these loaded during the test suite. > > Some also rely on other plugins. e.g. my function to dump the contents > of the innodb data dictionary* is.. well.. going to fail horribly > without embedded_innodb loaded. Currently I just have the > embedded_innodb plugin adding the function to the registry, but I > certainly don't want to ship it that way. I've considered adding a > "--i-really-know-what-i-am-doing-and-acknowledge-that-enabling-this-option-will-eat-babies-and-kill-puppies-so-please-just-enable-the-debug-plugins-for-embedded_innodb" > option... but i'd want to hide that too. > > thoughts? > > > Also, innobase and embedded_innodb conflict horribly. Load them both > at the same time and nothing will work. Any elegant way for us to do > "the right thing" and error out a bit more gracefully?
Give them the same name (name=innodb in plugin.ini if you're using DRIZZLE_PLUGIN or the second argument if you're using DRIZZLE_DECLARE_PLUGIN) I just pushed up a patch for review that fixes it so that we error out when there is a conflicting plugin name. :) > [*] yes, this function will become a data_dictionary table at some > point. some time after that branch is both working and mergable with trunk. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
