Information schema cleanup and improvements #49
Conversation
JanJakes
force-pushed
the
information-schema-cleanup
branch
from
efe431a to
87a14cb
Compare
The previous CTE approach modified only columns that were recorded in the statistics table, which was a bug for some DROP statements, when statistic data could already have been removed and as a result the column data was not correctly updated. The approach with a subquery solves that by updating all column records for a given table (resetting "column_key" to "" when there is no column key).
JanJakes
force-pushed
the
information-schema-cleanup
branch
from
87a14cb to
bd2c533
Compare
JanJakes
force-pushed
the
information-schema-cleanup
branch
from
8a731c7 to
5ed53f0
Compare
JanJakes
force-pushed
the
information-schema-cleanup
branch
from
489deb8 to
ad3f600
Compare
JanJakes
force-pushed
the
information-schema-cleanup
branch
from
129cc2f to
03d8ee5
Compare
|
|
||
| /* | ||
| * At the moment, we only support ASCII bytes in all identifiers. | ||
| * This is because SQLite doesn't support case-insensitive Unicode |
There was a problem hiding this comment.
It's great to surface this error in an explicit way, thank you!
Thinking about the future, if identifiers are case-insensitive in PHP, could we lowercase them effectively in PHP and pass the transformed names to SQLite? Although that opens more questions – are column names raw bytes, or are they normalized? Yeah, perhaps not going there is for the best.
There was a problem hiding this comment.
@adamziel It's definitely something we could solve on the PHP side (the simplest way probably requires mbstring), but yeah, we'd need to be careful exactly about what you mention — the column name will be stored as raw bytes in MySQL, but comparisons would need to be done normalized.
| return $name; | ||
| } | ||
|
|
||
| // The name is used - find the first unused name. |
There was a problem hiding this comment.
I don't suppose this would ever take a long time, but if it ever does we could explore uuids
There was a problem hiding this comment.
@adamziel Even in a table with hundreds of indexes, the time would probably be negligible. The reason why it's done exactly this way is that it's what MySQL seems to do, so it's nice to have it compatible.
|
@adamziel Thanks for such a quick review! ❤️ |
The information schema builder requires a few small touches for the new driver release:
table_constraintstable. This table will be needed in the future, and since it also store some information about primary and unique constraints, let's store it now, so we don't have to backfill it with a migration later on.