transaction_log plugin enable/disable sysvar does not work in call cases

[Joe Daly]

The sysvar for enable/disabling the transaction_log plugin currently is set to false by default when starting the server. If it is later enabled in the terminal by doing "set global transaction_log_enable=true;" This will result in the transaction_log still not being initialized. The initialization code is in the init() method and is blocked out by the sysvar to enable/disable the transaction_log. A way to fix this is to attach a function call to the sysvar variable so when its toggled the appropriate action is taken. The tests dont see this because each test is run with --transaction-log-enable on the command line for starting the server.

[Joe Daly (skinny.moey)]

I have a similar fix for my statistics work that I can apply to this as well.

[Joe Daly (skinny.moey)]

some comments from IRC, as this problem is not easily solved without adding to the confusion. Also worth noting is currently the transaction log can not be disabled once its started, that can be solved by adding a couple checks in the access points.

<jaypipes> jdaly: in the meantime, I'm considering that there might not be a good solution to this one... :(

<jaypipes> jdaly: let's discuss with mtaylor. monty, the problem is every plugin which implements I_S views must hide the registration of those views if the plugin is not "enabled". We have this weird mix of "activated plugins", "enabled plugins", and built-but-not-anywhere plugins...

<jaypipes> mtaylor: and if the registration of those I_S views is not hidden behind some "enabled" switch, the I_S views pop up in the information_schema.test case.

<jdaly> jaypipes: that works, I thought of not adding the columns to the I_S tables until its enabled, but I did that once and it gives a non descript error message and the table would still show up in the test case.

[Joe Daly (skinny.moey)]

Currently InfoSchemaTable has a variable (hidden) that allows the table to not show up in queries, its only exposed in the constructor currently. I think exposing this variable with a setter function is a good solution to this problem, this would allow toggling of the I_S table based on the state of the plugin. I ran a few tests with it and it worked well.

[Jay Pipes (jaypipes)]

OK, so I looked through the code in your branch and this indeed will
work. The other solution that I can think of is the following:

The reasons that we are doing this are:

1. To enable/disable certain plugins at runtime.
2. To "hide" views in the information_schema which are in plugins so
that they do not show up in the main.information_schema test case.

These two reasons may be solved in different ways. I think we can at
first focus on #2 above, possibly delaying a solution for #1 (because of
some of the complexities around locking that is necessary...)

For #2 above, we could do the following solution:

a) Add a new column to INFORMATION_SCHEMA.TABLES view with the following
definition:

PLUGIN_NAME VARCHAR(64) NULL

This column's value would be NULL for all base tables and would contain
the name of the plugin/module which it belongs to for all I_S views that
  are built by plugins.

Doing this would allow us to not have a hidden toggle at all, and
instead we could simply change the SQL SELECT in the
maion.information_schema test case to filter by:

WHERE TABLES.PLUGIN_NAME IS NULL

Joe, whatcha think? The above might be a bit more structured solution
that could be automated without each plugin developer having to call
toggleHidden() for each view, since the constructor for I_S views could
simply take the name of the plugin.

Cheers,

Jay

Joe Daly wrote:
> Currently InfoSchemaTable has a variable (hidden) that allows the table
> to not show up in queries, its only exposed in the constructor
> currently. I think exposing this variable with a setter function is a
> good solution to this problem, this would allow toggling of the I_S
> table based on the state of the plugin. I ran a few tests with it and
> it worked well.
>

[Joe Daly (skinny.moey)]

This seems very reasonable. I will go ahead and code this up, and remove the
hiding of the tables.

On Mon, Dec 28, 2009 at 9:14 AM, Jay Pipes <email address hidden> wrote:

> OK, so I looked through the code in your branch and this indeed will
> work. The other solution that I can think of is the following:
>
> The reasons that we are doing this are:
>
> 1. To enable/disable certain plugins at runtime.
> 2. To "hide" views in the information_schema which are in plugins so
> that they do not show up in the main.information_schema test case.
>
> These two reasons may be solved in different ways. I think we can at
> first focus on #2 above, possibly delaying a solution for #1 (because of
> some of the complexities around locking that is necessary...)
>
> For #2 above, we could do the following solution:
>
> a) Add a new column to INFORMATION_SCHEMA.TABLES view with the following
> definition:
>
> PLUGIN_NAME VARCHAR(64) NULL
>
> This column's value would be NULL for all base tables and would contain
> the name of the plugin/module which it belongs to for all I_S views that
> are built by plugins.
>
> Doing this would allow us to not have a hidden toggle at all, and
> instead we could simply change the SQL SELECT in the
> maion.information_schema test case to filter by:
>
> WHERE TABLES.PLUGIN_NAME IS NULL
>
> Joe, whatcha think? The above might be a bit more structured solution
> that could be automated without each plugin developer having to call
> toggleHidden() for each view, since the constructor for I_S views could
> simply take the name of the plugin.
>

Cheers,
>

Jay
>
> Joe Daly wrote:
> > Currently InfoSchemaTable has a variable (hidden) that allows the table
> > to not show up in queries, its only exposed in the constructor
> > currently. I think exposing this variable with a setter function is a
> > good solution to this problem, this would allow toggling of the I_S
> > table based on the state of the plugin. I ran a few tests with it and
> > it worked well.
> >
>
> --
> transaction_log plugin enable/disable sysvar does not work in call cases
> https://bugs.launchpad.net/bugs/499596
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in A Lightweight SQL Database for Cloud and Web: Confirmed
>
> Bug description:
> The sysvar for enable/disabling the transaction_log plugin currently is set
> to false by default when starting the server. If it is later enabled in the
> terminal by doing "set global transaction_log_enable=true;" This will result
> in the transaction_log still not being initialized. The initialization code
> is in the init() method and is blocked out by the sysvar to enable/disable
> the transaction_log. A way to fix this is to attach a function call to the
> sysvar variable so when its toggled the appropriate action is taken. The
> tests dont see this because each test is run with --transaction-log-enable
> on the command line for starting the server.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/drizzle/+bug/499596/+subscribe
>

[Joe Daly (skinny.moey)]

I believe the runtime enable/disable of plugins is getting delayed for a bit for locking, should the transaction log plugin be changed to remove the runtime enable/disable code. Its state currently is a bit misleading as if you dont enable it on starting you have to restart the server.

[Stewart Smith (stewart)]

Since we don't ship the basic transaction_log plugin, marking as Invalid (even though in the past, this bug was valid)