Rafal,
I need an explanation on one part of your comments...
...
> > +
> > +/**
> > + Serialize the object.
> > +
> > + This method produces the data necessary for materializing the
> > + object on restore (creates object).
> > +
> > + @param[in] thd Thread context.
> > + @param[out] serialization The data needed to recreate
> this object.
> > +
> > + @note this method will return an error if the db_name is either
> > + mysql or information_schema as these are not objects that
> > + should be recreated using this interface.
> > +
>
> Why privileges to the internal tables should not be
> serializable using this interface? The fact that we don't do
> it in backup kernel is not enough to exclude such possibility
> (especially if implementing the restiction means extra work).
>
> In the kernel we will simply call is_internal_db_name() to
> detect an internal database and not query or execute
> privileges for such databases.
I don't understand this comment. Please explain.
Also, I will document privilege better in the code, but allow me to explain
it here.
Privilege are things like SELECT, UPDATE, INSERT, etc. We need to know this
information in order to materialize or serialize a grant (from the
SCHEMA_PRIVILEGES table only -- the others require more data). We must also
know the user (grantee) and database.
If on restore, all we have are user_name (grantee), database, and privilege
we can construct the proper GRANT statement and execute it. However, I
thought we were still storing entire SQL commands in the backup image. If
so, we would create this statement at backup and simply execute them at
restore time. Note that some of the code I added enables us to materialize a
db grant from the three pieces of information. Note also that it is not
enough to simply store a list of users as there could be several grantee
strings for a single user.
I have documented this in the LLD of the worklog. Let me know if this
explains it plainly enough.
Chuck