Chuck Bell wrote:
> 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.
>
You implemented serialize() method so that it returns error if the object is an
internal database. In effect it is not possible to serialize an internal
database using this API.
I am objecting that we need such restriction here. I would say that it is better
(more flexible) to have a possibility to serialize any database, including the
internal ones.
It is true that in the backup kernel we don't want to backup and restore
internal databases. But this can be achieved by just skipping the internal
databases in the kernel code - for that we need a function which tells us that a
given database is internal.
Is it more clear now?
> 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.
Agree. When we serialize, we get "this information" from the I_S tables (more
precisely, we read the information from I_S tables when we create the privileges
object and store it in it, then use stored information when we serialize the
object). For materialize operation it is different - in that case the
information is contained in the serialization string.
>
> 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.
At restore time, for each saved grant we have this information: database, user
and serialization string. If serialization string is a complete GRANT statement,
then the database and user information is redundant (but we keep it in the
backup image nevertheless to beter describe its contents).
> If
> so, we would create this statement at backup and simply execute them at
> restore time.
That is one possibility. Another one, which I'm advocating, is to not store a
complete statement but just the information needed to construct it at restore
time. Since database and user are known at restore time, the only information
which must be stored in the serialization string is the list of grants (INSERT,
UPDATE etc.) and the subject of the grant (i.e. the table, procedure, etc. to
which the grants apply, or the "all objects" wildcard).
> Note that some of the code I added enables us to materialize a
> db grant from the three pieces of information.
In the API, we materialize db grants only from their serialization strings. Of
course, when you create grant objects inside grant iterator you must provide all
three pieces of information to the constructor. But this is not the same with
materialization from a serialization string.
> 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 tend to think that, for the backup system, a user is always a "<user
name>@<host pattern>" pair - so we don't consider just user names. This, I
think, is in line with how users are treated in the server. E.g if you CREATE
USER, always a "<user name>@<host pattern>" pair will be created.
> I have documented this in the LLD of the worklog. Let me know if this
> explains it plainly enough.
>
Ok, I'll look at the designs and send my comments.
Rafal
