feat: correct column order

[dust1]

Which issue does this PR close?

Closes #187

Rationale for this change

Table' columns order is not what user define when create table

What changes are included in this PR?

I modified the 'add_key_column' and 'add_normal_column' methods in 'schema.builder' and added 'primary_key_index' to record additional field primary key information.

Of course this affects the subsequent storage logic.

I removed num_key_size from RecordSchemaWithKey and added key_index to confirm the location of the primary key.

The end result:

mysql> CREATE TABLE `demo` (`name` string TAG, `value` double NOT NULL, `t` timestamp NOT NULL, TIMESTAMP KEY(t)) ENGINE=Analytic with (enable_ttl='false');
Query OK, 0 rows affected (0.02 sec)

mysql> insert into demo (name, value, t) values ('zaaaaasss', 1.112, 1651737061500);
Query OK, 1 row affected (0.00 sec)

mysql> insert into demo (name, value, t) values ('zaaaaasss', 1.112, 1651737061100);
Query OK, 1 row affected (0.00 sec)

mysql> select * from demo;
+-----------+-------+---------------+---------------------+
| name      | value | t             | tsid                |
+-----------+-------+---------------+---------------------+
| zaaaaasss | 1.112 | 1651737061100 | 3511143416174120951 |
| zaaaaasss | 1.112 | 1651737061500 | 3511143416174120951 |
+-----------+-------+---------------+---------------------+
2 rows in set (0.00 sec)

mysql> desc demo;
+-------+-----------+------------+-------------+--------+
| name  | type      | is_primary | is_nullable | is_tag |
+-------+-----------+------------+-------------+--------+
| name  | string    |          0 |           1 |      1 |
| value | double    |          0 |           0 |      0 |
| t     | timestamp |          1 |           0 |      0 |
| tsid  | uint64    |          1 |           0 |      0 |
+-------+-----------+------------+-------------+--------+
4 rows in set (0.00 sec)

Are there any user-facing changes?

How does this change test

I change two unit test in schema.rs. in L1597 and L1600, I changed the field validation order, make the order of the fields consistent with the order in which they were created

[jiacai2050]

@dust1 It seems your branch is kinds of stale, please rebase with latest main branch.

[dust1]

ok

[ShiKaiWi]

In my understanding, these changes are sufficient, but when I test the new table, I find that the primary_key_index is empty in the data re-read by wal log. I need more time to check the reason

@dust1 Have you figured out this problem? I can help do some troubleshooting if you will. Don't worry about the time because this pr is not urgent for us.

[dust1]

In my understanding, these changes are sufficient, but when I test the new table, I find that the primary_key_index is empty in the data re-read by wal log. I need more time to check the reason

@dust1 Have you figured out this problem? I can help do some troubleshooting if you will. Don't worry about the time because this pr is not urgent for us.

thank you @ShiKaiWi 🥰. Maybe I've already done this pr

[jiacai2050]

LGTM