Hi, Sergei
I am so sorry. It should be week 13 report, instead of 12.
>
> Hi,
>
> KEY ACCOMPLISHMENTS LAST WEEK
> ==============================
> Analysed get_all_tables() and all I_S tables based on file system.
> Added I_S tables: TABLE_NAMES, PARTITIONS, TABLES and VIEWS.
> TABLE_NAMES and PARTITIONS work well, but TABLES and VIEWS do not.
>
I have fixed bugs of TABLE and VIEWS. But new bug is shown.
If run "SELECT * FROM information_schema.TABLES" or "SELECT * FROM
INFOSCHEMA.TABLES" more than 2 times,
MySQL server will crash on "Field::clone". The problem should be issued by
infoschema_discover, which does not set field->ptr right, like
the bug we meet before. But I check infoschema_discover many times, I can't
find what is wrong.
KEY TASKS THAT STALLED LAST WEEK
> ===============================
> Behind the schedule. I am speeding up.
>
> KEY CONCERNS
> ============
> 1. I changed my Email address. Because my national email provider does
> not support mail list very well and I find I have lost lots of msg
> from internal mail lsit.
>
> 2. I implement I_S tables based on file systems like this:
> For non-index: In rnd_init, I_S storage engine make up all database names
> and table names in List<LEX_STRING> structures.
> In rnd_next, I_S storage engine walks through all
> database names and table names to fetch specific data. You
> can check the important function
> get_all_tables_for_i_s() in sql_show.cc.
> This method is easy to implement tables, where a
> database name and a table name determine one row, like
> TABLE_NAMES. But if one table contains lots of
> rows, like TRIGGERS, COLUMNS and etc, it is more complicated. Do you have
> any advices?
>
I find out a good idea to do that. I will implement this two - three days.
For index: In index related functions, those functions make up related
> database names and table names according by "WHERE .." and
> "LIKE ..". The remaining is similar with non-index. I
> have implemented TABLE_NAMES, PARTITIONS, TABLES and VIEWS, but no
> index yet. If you agree with this, I will continue doing
> like this. If you have time, could you take
> some time to check TABLES? Why does it crash. -_-!
>
The bug have moved to infoschema_discover. -_-!
3. I have added lots of xxxx_for_i_s functions in sql_show.cc. I think
> it not good for plugin type. If I extract them into others file, there
> are lots of variables and functions do not
> define or forword-definition errors.
>
> 4. The time line of GSoC says 17 Aug is the last evaluation, and 3 Sep
> we can post the code to Google. Between 17 Aug and 3 Sep, could I
> continue coding? On 17 Aug, what kind
> of I_S storage engine do you expect to see?
>
I just think the remaing time is a little short. But I believe I can finish
it.
Regards,
Robin
