can't alter access_* settings

[githubmanticore]

In version Manticore 3.4.3 d74eea9@200601 dev I cannot alter index settings access_* :

mysql> show index t3 settings; 
+---------------+-------+ 
| Variable_name | Value | 
+---------------+-------+ 
| settings      |       | 
+---------------+-------+ 
1 row in set (0.00 sec) 
 
mysql> alter table t3 access_plain_attrs='mlock' access_blob_attrs='mlock'; 
Query OK, 0 rows affected (0.00 sec) 
 
mysql> show index t3 settings; 
+---------------+-------+ 
| Variable_name | Value | 
+---------------+-------+ 
| settings      |       | 
+---------------+-------+ 
1 row in set (0.00 sec) 
 
mysql> show create table t3; 
+-------+----------------------------+ 
| Table | Create Table               | 
+-------+----------------------------+ 
| t3    | CREATE TABLE t3 ( 
f text 
) | 
+-------+----------------------------+ 
1 row in set (0.00 sec) 

It's not convenient as requires full RT index rebuild if I just want to mlock it in memory.

[githubmanticore]

➤ Stan commented:

there are similar options that reads from regular config and might be replaced by daemon default values:

• global_idf
• access_*
• preopen
• expand_keywords

Change of these options needs reload of index as some of them got applied only on index load.

It also not clear how to reset these options to daemon defaults in case these options will be saved into index header.
In case we will write them into JSON config to backup index someone need backup and this part of config too.

[githubmanticore]

➤ Sergey Nikolaev commented:

The specification is:

• just as now

  searchd {  
    access_plain_attrs=mlock  
  }   
  

  allows to define per-instance setting (no changes here at all, just global setting which is used in case there’s no per-index setting)

• when one runs

  ALTER TABLE idx access_plain_attrs='mlock';   
  

  it applies these settings to all nodes in the cluster.

• this

  ALTER TABLE idx override access_plain_attrs='mlock';  
  

  overrides cluster settings on a local node in case it’s required (should be required seldom and be considered an exception).

• SHOW CREATE TABLE ...   
  

  displays CREATE TABLE ... access_plain_attrs and additionally second command `ALTER ... override``` which provides the overridden settings.

• here

  SHOW INDEX ... SETTINGS  
  

  will be no changes. SHOW CREATE TABLE should be enough.

• CREATE TABLE LIKE ...  
  

  should also respect access_plain_attrs / overridden access_plain_attrs

ALTER … override triggers:

• saving it in global json config (to prevent replication)

Changing non-override settings via ALTER triggers:

• saving it in per-index json config
• replicating it

Changing both override and non-override settings is not allowed. I.e. you can either do just ALTER or ALTER ... override

By default changing index settings should not trigger reloading of the index, because then there may be a problem with its accessibility in case it’s in a cluster if it’s being reloaded on all the nodes at the same time. It’s safer to let user run RELOAD INDEX.
For ease of use additionally we can add support of ALTER TABLE ... reload='now' and ALTER TABLE ... reload='graceful' to reload all at the same time or one by one. In the both cases reload can be the only change you provide in the ALTER (like in MySQL where it’s a common practice to run ALTER TABLE tbl ENGINE=innodb even if it already has ENGINE=innodb for table optimization).

For ease of use additionally we can add support of RELOAD INDEX <rt index> replicate='{now|graceful}' to reload all at the same time or one by one.

In terms of priorities the order is:

1. ALTER access_ - to save it in per-index json and SHOW CREATE TABLE to read and display it from there. This is priority 1 as there’s no way to change access_* for an index which in some cases is not convenient. On the other hand it's seldom required to have per-index access_* settings.
2. replication of the per-index json on ALTER
3. ALTER override - to save in global json and SHOW CREATE TABLE to read and display it from there
4. RELOAD <rtindex>
5. RELOAD ... replicate - to replicate index reloading

Sub-tasks are to be created.