Bug #34705 FALCON_TABLES shows wrong TABLE_NAME
Submitted: 20 Feb 2008 21:14 Modified: 18 Oct 2008 15:58
Reporter: Hakan Küçükyılmaz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:6.0.4, 6.0.5 OS:Any
Assigned to: Sergey Vojtovich CPU Architecture:Any
Triage: D3 (Medium)

[20 Feb 2008 21:14] Hakan Küçükyılmaz
Description:
It appears that if TABLE_NAME contains characters outside of ASCII, you can not use the "escaped" TABLE_NAME to drop the table.

How to repeat:
For example:

mysql> create table `###` (f1 integer not null) engine=falcon;
Query OK, 0 rows affected (0.01 sec)

mysql> select * FROM information_schema.FALCON_TABLES;
+-------------+-----------------+-----------+------------------+-----------------+
| SCHEMA_NAME | TABLE_NAME      | PARTITION | TABLESPACE       | INTERNAL_NAME   |
+-------------+-----------------+-----------+------------------+-----------------+
| TEST        | T3              |           | FALCON_TEMPORARY | T3              |
| TEST        | T12             |           | FALCON_TEMPORARY | T12             |
| TEST        | @0023@0023@0023 |           | FALCON_USER      | @0023@0023@0023 |
+-------------+-----------------+-----------+------------------+-----------------+

mysql> drop table `@0023@0023@0023`;
ERROR 1051 (42S02): Unknown table '@0023@0023@0023'

This means that one can not safely iterate over all rows of FALCON_TABLES and perform
operations on individual tables. Unless one manually converts @0023@0023@0023 into a ###,
there is no way to match that table to , say, information_schema.TABLES, because the
@0023@0023@0023 does not appear there, just the ###.
[20 Feb 2008 21:59] Sveta Smirnova
Thank you for the report.

Verified as described.
[28 Mar 2008 10:33] Vladislav Vaintroub
Kevin,
I'm not sure that something has to be done to it.Falcon never sees ### , server passes only the encoded string to it (@0023@0023@0023), in fact together with path. encoding/decoding is not made a public (plugin accessible) API. 

I believe the problem the difference in perception of "table" between plugin API and Falcon- server is talking in filesystem path terms, Falcon needs table names and tablespaces. Thus for the time being, I'd classify that as 'Won't fix' - if server would pass the schema and table names directly, the problem would not ever exist.

The problem described by Hakan (inability to use table names from falcon_tables)
BTW is simply solved - use standard information_schema.tables for any purposes.

In exotic cases, like manual error analysis and debugging, well then one could live with @0023 as well.
[28 Mar 2008 14:03] Vladislav Vaintroub
Well, after some debugging around found that a some info is passed in little
documented HA_CREATE_INFO structure and it has a member named 'alias'
that looks like undecorated table name.
[18 Jul 2008 0:15] Kevin Lewis
Assigning to Sergey Votjovich.  We have decided to delete INFORMATION_SCHEME.FALCON_TABLES which should eliminate this problem.

>>Vlad wrote;
>>
>> How would you fix these bugs? For example, to have proper table name as
>> defined by user (in all cases, that is even with non-latin characters and
>> after RENAME) we would need  filename_to_tablename() , that is banned from
>> server API.  And possibly we'd also need to fix Falcon uppercasing while
>> we are at it ;) Too much hacking, is not it?

>Ann wrote;
>Too much hacking and too little value, I agree.  Also too much confusion
>about what table to trust, giving that there is a very large overlap
>between TABLES and FALCON_TABLES.  I can think of no case where the
>internal Falcon name is of interest to anything but Falcon.  So, fine,
>lets get rid of FALCON_TABLES and close all three bugs.
[30 Jul 2008 21:36] Kevin Lewis
See http://lists.mysql.com/commits/50640
[31 Jul 2008 10:23] Sergey Vojtovich
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/50640

2761 Sergey Vojtovich	2008-07-29
      BUG#29211 - Falcon: information_schema has a falcon_tables view
      BUG#34705 - FALCON_TABLES shows wrong TABLE_NAME
      BUG#34706 - FALCON_TABLES shows wrong information on temporary tables
      
      There were several problems relating to INFORMATION_SCHEMA.FALCON_TABLES,
      e.g.:
      - there is no worklog entry for I_S.FALCON_TABLES, so it is not
        there by design
      - MySQL already has I_S.FILES and I_S.TABLES, which provide
        duplicating information
      - it didn't show properly table names with non-ascii characters
      - it didn't show properly table and schema names for temporary
        tables
      
      This patch removes INFORMATION_SCHEMA.FALCON_TABLES and all
      relevant code.
      
      No test case needed for this fix - it is already covered by existing
      tests.
[18 Aug 2008 11:17] Sergey Vojtovich
Was pushed to 6.0.7.
[14 Sep 2008 3:53] Bugs System
Pushed into 6.0.7-alpha  (revid:svoj@mysql.com-20080729104539-5grheqzat2gs0avq) (version source revid:v.narayanan@sun.com-20080820070709-nx09bk6qx81osd5s) (pib:3)
[18 Oct 2008 15:58] Jon Stephens
Documented in the 6.0.7 changelog as follows:

        *IMPORTANT CHANGE* The INFORMATION_SCHEMA.FALCON_TABLES table has been 
        removed.

Updated se-falcon-stats section of 6.0 Manual accordingly.