Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FLASH-175]eliminate assumption of existence of tidb_rowid #35

Closed
wants to merge 5 commits into from
Closed

[FLASH-175]eliminate assumption of existence of tidb_rowid #35

wants to merge 5 commits into from

Conversation

lidezhu
Copy link
Contributor

@lidezhu lidezhu commented Apr 4, 2019

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

@lidezhu lidezhu requested review from innerr and solotzg April 4, 2019 05:20
@lidezhu lidezhu changed the title eliminate assumption of existence of tidb_rowid [FLASH-175]eliminate assumption of existence of tidb_rowid Apr 4, 2019
@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 4, 2019

/rebuild

1 similar comment
@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 4, 2019

/rebuild

@@ -127,7 +131,8 @@ TableID MockTiDB::newTable(const String & database_name, const String & table_na
table_info.columns.emplace_back(column_info);
}

table_info.pk_is_handle = false;
table_info.pk_is_handle = !(primary_key.empty());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pk is handle != no pk

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix it.

@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 6, 2019

/rebuild

@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 9, 2019

/rebuild

2 similar comments
@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 9, 2019

/rebuild

@lidezhu
Copy link
Contributor Author

lidezhu commented Apr 9, 2019

/rebuild

}
}
block = readProcess(block, typeid_cast<const ColumnInt32 *>(handle_column.column.get()));
} else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a chance that the handle column is of type other than int64 or int32? I.e. int16 or int8?

Try creating a tidb table with single column primary key of type short or tiny int or whatever, then you'll see.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have included other cases when the handle column is of other int type.

@@ -22,60 +76,21 @@ Block RangesFilterBlockInputStream::readImpl()
throw Exception("RangesFilterBlockInputStream: block without _tidb_rowid.", ErrorCodes::LOGICAL_ERROR);

const ColumnWithTypeAndName & handle_column = block.getByName(handle_col_name);
const ColumnInt64 * column = typeid_cast<const ColumnInt64 *>(handle_column.column.get());
if (!column)
std::string handle_column_type_name = std::string(handle_column.type->getFamilyName());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reduce unnecessary memory allocation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix it.

@@ -67,7 +67,7 @@ void MockTiDB::dropTable(const String & database_name, const String & table_name
tables_by_name.erase(it_by_name);
}

TableID MockTiDB::newTable(const String & database_name, const String & table_name, const ColumnsDescription & columns)
TableID MockTiDB::newTable(const String & database_name, const String & table_name, const ColumnsDescription & columns, const String & primary_key, bool pk_is_handle)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need argument pk_is_handle, it can be inferred by the given column list and pk (and this is actually how TiDB does):

  1. Single pk column.
  2. The pk column is of integral type, i.e. int8/16/24/32/64.

Besides, you have to be clear of the function semantic by answering the following questions:

  1. Does it allow specifying multiple primary keys? If no (as it already is), it probably means that you are assuming the only primary key specified is valid. But it might be not, as it could be of non-integral type.
  2. If the answer to the above question is yes, it means you will check the the given primary key list and decide whether pk_is_handle, and error out or just let it be.
  3. Either way, you are missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Eliminate pk_is_handle and pk column can be other kinds of int type now.
  2. The current semantic is user can only specify one column to be the primary key and it must be one of int type. The reason for this choice is that when the primary key contain multiple columns, table_info structure does not store the order between multiple columns inside a primary key. And parse a primary key which consists of multiple columns is more troublesome and the information is currently useless.

@zanmato1984
Copy link
Contributor

Fixed in #47
Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants