From: Haihao Tang
Date: August 4 2009 5:16am
Subject: Re: GSoC Week 13 - I_S/P_S storage engine
List-Archive: http://lists.mysql.com/soc/433
Message-Id: <c0e3979f0908032216x5c2f8045r8e438cdfaa7a704e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=001485f99c7e1c8b9b047049fceb

--001485f99c7e1c8b9b047049fceb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--001485f99c7e1c8b9b047049fceb--