List:Summer of Code« Previous MessageNext Message »
From:Haihao Tang Date:August 4 2009 5:16am
Subject:Re: GSoC Week 13 - I_S/P_S storage engine
View as plain text  
Hi, Sergei

I am so sorry. It should be week 13 report, instead of 12.

> Hi,
> ==============================
> Analysed get_all_tables() and all I_S tables based on file system.
> 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.

> ===============================
> Behind the schedule. I am speeding up.
> ============
> 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
>                         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 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


Re: GSoC Week 13 - I_S/P_S storage engineHaihao Tang4 Aug
  • Re: GSoC Week 13 - I_S/P_S storage engineSergei Golubchik6 Aug
  • Re: GSoC Week 13 - I_S/P_S storage engineSergei Golubchik6 Aug