WL#3048: partitioning fixes
Affects: Server-7.1 — Status: Un-Assigned — Priority: Medium
remove mysql_wait_completed_table function, .par fle and handler::create_handler_files(). make packfrm to be called out of ha_ndbcluster, not from generic alter table code. handle_opt_part/print_error bug
mysql_wait_completed_table ^^^^^^^^^^^^^^^^^^^^^^^^^^ it's not necessary, there's no need to wait at the end, only makes sense to wait before doing something. .par file and handler::create_handler_files() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sergei: what is that ? why do you need handler::create_handler_files ? to write .par file, you will say. Problems are: 1. it's basically useless for any other storage engine - "handler files" (e.g. MRG, MYD, MYI, ARN, etc) are created in handler::create 2. ha_partition uses it incorrectly - in CREATE TABLE, .par file should be created in ::create, subject to all the conditions that apply to ::create, e.g. if (!create_info->frm_only), and whatever may be introduced later. so the method is not for "creating handler files" (as it's the task of ::create), what is it for ? let's see ha_partition::create also creates underlying partitions, while create_handler_files() only changes the partition list. So it's for changing metadata without touching the data, Fine, but 3. create_handler_files() could only help when changing partition information, modifying other metadata (indexes, column types) cannot be done with create_handler_files(). Thus, it's not even "update_table_metadata" method. It's "update_partition_metadata_without_doing_real_partition_changes" I don't think class handler needs such a method. 4. You invented binary format to store partition information in .par file but you use sql to store it in frm. Why ? A better solution: - keep metadata only in .frm - as csv, archive, federated do. Mikael: the handler file .par was invented for one and only one purpose. This is that rename_table and delete_table can be called on tables that are not opened. Thus the only way to discover the names of the partitions for this table is to save it in a separate file unless I should do some strange murky thing by from the handler open the table. And yes, it is a very specific ha_partition problem that I don't expect other handlers to have so I could make it a specific ha_partition call if that would be better. Monty: in 5.1 there is a function to open only .frm, without opening handler files. It should be used here instead of .par file. packfrm ^^^^^^^ no need for a packfrm here. why should MySQL compress the frm before giving it to the handler ? the latter may want to parse/analyze it (especially when frm will be plaintext) if NDB wants to compress is to reduce the traffic and to store it in machine-independent format, it's details of ndb implementation, other handlers may not need it. Thus, MySQL should give frm to the handler as is, and ndb will pack it internally. handle_opt_part/print_error bug ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ handle_opt_part calls handler::print_error(), passing the return value of handler admin command. Handler admin commands return HA_ADMIN_xxx codes, while print_error expects HA_ERR_xxx code. no_xxx variables ^^^^^^^^^^^^^^^^ rename all no_xxx variables in partitioning code to num_xxx (e.g. no_partitions to num_partitions) as it confuses everybody who looks at the code. don't use db_type ^^^^^^^^^^^^^^^^^ Partitioning handler relies on stable db_type values. This is wrong - loadable storage engine don't provide them. Currently ha_partition stores db_type for partitions in .frm and in .par. The latter will solve itself when .par will go away. The former - as full partitioning syntax is stored as plain SQL in .frm file, it could just as well use ENGINE=xxx that is part of that syntax.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.