Explicitly specify storage features#8830
Conversation
…ystem.table_engines table, properly check feature support in storage factory.
|
Ok. |
|
We have some properties in virtual methods of IStorage. Some of them depends on concrete table instance (not only on engine type) but maybe some of them worth moving out to factory. |
This PR mainly focuses on fixing the issue of not being able to specify some clauses in engine specification for third-party engines, the rest of work is done on my personal "sense of beauty" basis and presented here for the sake of PR completeness :) Though I agree that moving some of the IStorage per-query features to factory is definitely a good idea, I think it is more an informativeness (and documentation) improvement rather than what is done here. Also, I do not feel 100% sure which features are worth exposing them in the system.table_engines table. I would be glad if anybody suggests me which of the |
Those that always return true/false. |
This plan excludes almost all features (except for Maybe we should introduce special value of 2 (or null) for this flag indicating that certain feature may be supported or not depending on the particular table? |
Not necessary. Just move only those features that are constantly true or false... |
|
|
Maybe just array? It's easier to extend and horizontal output is not so wide. Checking with |
|
@filimonov Separate columns is more ClickHouse style. |
|
Fixed segfault, added supports_replication and supports_deduplication.
I have no strong opinion on this, but n columns seems OK for me. |
alexey-milovidov
left a comment
There was a problem hiding this comment.
Ok.
There is no functional test for new columns. And virtual methods from IStorage were not removed.
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
There are several features that are supported by a certain subset of storages like support of TTL, key/sort order specification, settings specification or skipping indices support. As for today, ClickHouse checks if given table engine supports these features in storage factory by hard-coded rules like "if ORDER BY is specified then storage name should end with MergeTree". Such logic blocks third-party storage engines to support similar features, for example, if ClickHouse is used as a library in third-party application which provides its own storage engine supporting TTLs, there is no way to use it as StorageFactory will throw an exception.
This PR does the following:
supports_settings,supports_skipping_indices,supports_ttlandsupports_sort_order;system.table_enginesis extended with information about feature support in following manner:Disclaimer: I divided features into these four groups according to my understanding of their logic. Feel free to suggest a better division into groups or better naming.
Specify supported properties for each storage engine, expose them via system.table_engines table, properly check property support in storage factory.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
System table
system.table_enginenow provides information about feature support (likesupports_ttlorsupports_sort_order).Detailed description / Documentation draft:
System table system.table_engines is currently not documented at all, so a documentation draft for this table is included as a second commit.