MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:July 14 2009 4:02pm
Subject:Re: GSoC Week 10 - I_S/P_S storage engine
View as plain text  
Hi, scut_tang!

On Jul 14, scut_tang wrote:
> Hi,
> 
> KEY ACCOMPLISHMENTS LAST WEEK
> ==============================
> 1. Almost finish tables ENGINES and COLLATIONS fetching data
> functions. But they met the same problem, it is descripted in KEY
> CONCERNS.
> 2. Finish infoschema_find_files.
> 3. Change a little of hierarchy for the I_S tables, separated I_S
> tables by index and non-index. But still leave some required change in
> index implementation phase.

I want to see your changes, especially when you have problems.
Sending patches around is not very convenient - I've created a project
on launchpad, and added you there in the "maintainer" team, I suppose
you should be able to push here:

   lp:~sergii/mysql-infoschema/trunk

As you could not finish the push last time, I suggest not to try pushing
your tree there, but instead branch that url above, apply your changes
to the new tree as a patch, commit, and push.
 
> KEY CONCERNS
> ============
> 1. When I call "SELECT * FROM INFOSCHEMA.ENGINES/COLLATIONS", they are
> crashed at table->field[0]->store(...). 
>   SHOW CREATE TABLE INFOSCHEMA.TABLES crashed too, and add
>   "DEBUG_RETURN(HA_ERR_WRONG_COMMAND)" into ha_infoschema::create()
>   does not work.
>   I think all these crashes are caused by the incomplete filled
>   table_share. Sergei, could you check infoschema_discover?

please push your changes, I'll have a look.

> 2. I don't use init_tmp_table_share in infoschema_discover, because it
>    won't work. When I used it, MySQL returned "table does not exist".
>    I think some fields filled by init_tmp_table_share are not fit for
>    us.

please push your changes, I'll have a look.

> 3.const char *index_type(uint inx)
>   {
>      return "HASH";
>   }
>   I don't think I_S storage engine use neither HASH nor BTREE, because
>   the indice are based on file system, not HASH and BTREE. Could I add
>   one more index type, like FSYSTEM?

No, instead of coming up with new names think of what operations your
index supports. Does it support ranges like a btree ? "all file names
between abc and adef" - no, it cannot easily do that.

In that sense it's closer to HASH.

But it can do prefix searches ("filenames that start with "ab"), and it
can be taught to do ranges - so it can be called BTREE, but it's more
work, and we should concentrate on the basic functionality first.

> 4. I don't know clearly about table->record[0-2]. Is table->record[0]
> connected with table->filed[]'s data?

Correct.

> 5. '#define MYSQL_SERVER 1' should be in ha_infoschema.cc. If not,
> lots of functions we can't use, which declare in mysql_priv.h.

okay.
 
Regards / Mit vielen GrЭъen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB MЭnchen 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
GeschДftsfЭhrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin HДring
Thread
OS/2 3.23.32: merge test failingYuri Dario27 Jan
  • Re: GSoC Week 10 - I_S/P_S storage engineSergei Golubchik18 Jul
  • Re: GSoC Week 10 - I_S/P_S storage engineSergei Golubchik18 Jul
Re: OS/2 3.23.32: merge test failingYuri Dario27 Jan