Conversation
|
TODO:
|
| second_column UInt8 DEFAULT 1 EXPRESSION rand() % 222, | ||
| third_column String DEFAULT 'qqq' | ||
| ) | ||
| PRIMARY KEY key_column, second_column |
There was a problem hiding this comment.
This one looks pretty cool, but inconsistent with current implementation for MergeTree ordering/pkey qualifier, which requires (key_column, second_column) format.
Just wondering - would this approach become available for ordinal table creation as well (in future)?
There was a problem hiding this comment.
I don't see anything against your proposal. Maybe it would be better to make round brackets optional for dictionaries.
| ) | ||
| PRIMARY KEY key_column | ||
| SOURCE(CLICKHOUSE(HOST 'localhost' PORT 9000 USER 'default' TABLE 'table_for_dict' PASSWORD '' DB 'database_for_dict')) | ||
| LIFETIME(MIN 1 MAX 10) |
There was a problem hiding this comment.
As I can see - we have here two mandatory options (min, max). Maybe, it is better to omit them, allowing to specify in a form like LIFETIME(1,10)?
Pros:
- No extra syntax constructions needed
- Less symbols to type :)
- Looks more native for SQL users (like function call)
Cons:
- If lifetime will have more complicated configuration, it will get stuck. E.g.:
LIFETIME(MAX 10 IF_ONCE_QUERIED_REMEMBER_FOREVER 1)(here MIN 1 is omitted, but another option is introduced)
There was a problem hiding this comment.
Current LIFETIME definition is consistent with other parts RANGE, SOURCE , etc.
|
|
||
| SELECT dictGetString('database_for_dict.dictionary_with_hierarchy', 'RegionName', toUInt64(2)); | ||
| SELECT dictGetHierarchy('database_for_dict.dictionary_with_hierarchy', toUInt64(3)); | ||
| SELECT dictIsIn('database_for_dict.dictionary_with_hierarchy', toUInt64(3), toUInt64(2)); |
There was a problem hiding this comment.
will it be posiible to have dict with same name in 2 different databases?
| LIFETIME(MIN 1 MAX 10) | ||
| LAYOUT(FLAT()); | ||
|
|
||
| SELECT count(*) from database_for_dict.dict1; |
There was a problem hiding this comment.
does it mean that it will also allow to access dictionaries data with simple select (as with Engine=Dictionary)?
| SELECT second_column FROM database_for_dict.dict1 WHERE key_column = 11; | ||
| SELECT dictGetString('database_for_dict.dict1', 'third_column', toUInt64(12)); | ||
| SELECT third_column FROM database_for_dict.dict1 WHERE key_column = 12; | ||
| SELECT dictGetFloat64('database_for_dict.dict1', 'fourth_column', toUInt64(14)); |
There was a problem hiding this comment.
is database part in dictionary name mandatory? Or it will use current database / global scope if not provided?
There was a problem hiding this comment.
As tables, it will use the current database.
There was a problem hiding this comment.
how that will work with existing dicts (defined in "global"context)
There was a problem hiding this comment.
For existing dictionaries, you have to used the full name in dictGet* functions. For normal selects, you have to create database with an engine Dictionary().
|
|
||
| SHOW DICTIONARIES FROM ordinary_db LIKE 'dict1'; | ||
|
|
||
| EXISTS DICTIONARY ordinary_db.dict1; |
There was a problem hiding this comment.
and what will happen if same dict is described both in xml and ddl?
There was a problem hiding this comment.
I hope we will not be able to load dictionary and got an exception on creation, but I need to add test for this!
|
my own tests failed :( I have missed config file :( |
|
@alexey-milovidov recommend to merge this PR. |
| auto & external_loader = context.getExternalDictionariesLoader(); | ||
| external_loader.addConfigRepository(getDatabaseName(), std::move(dictionaries_repository)); | ||
| bool lazy_load = context.getConfigRef().getBool("dictionaries_lazy_load", true); | ||
| external_loader.reload(!lazy_load); |
There was a problem hiding this comment.
So after this change all dictionaries will be reloaded, regardless the lifetime?
And this can be not the desired behavior if the dictionary is big enough
This ignores any lifetime, while dictionaries can be quite big. Fixes: c7cd911 ("Merge pull request ClickHouse#7360") Refs: ClickHouse#7360 (comment)
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
For changelog. Remove if this is non-significant change.
Category (leave one):
Short description (up to few sentences):
Add the ability to create dictionaries with DDL queries.