Mnesia - table change
Mnesia has a lot of useful things: stores data in Erlang format, replication, transactions, etc. etc. But there is one problem - how to change table structures?
When creating a table, you must specify a list of fields. We will not go deep into the recommendation to use a record of the same name with the table. It is important that when changing the list of fields according to the option proposed in the documentation using mnesia: transform_table (converting fields and replacing the table definition), it seems that you will have to stop the system, convert the table, change the application code to work with the new type and start (testing).
If you look at any SQL database, then adding a field is an elementary operation.
It is important for me to switch to a new type without stopping the entire system. At the very least, the database should function continuously.
I researched reading and writing in Mnesia. And the conclusion is:
Mnesia tightly controls the data during recording. You can write only what is declared in the table structure, otherwise an error. The name of the record and the number of elements is controlled - i.e. ALL.
However, when reading, Mnesia gives away what was written, without checking the current configured list of fields and the name of the record. And the list of fields can be changed without actually transforming records using the not recommended mnesia form: transform_table (Tab, ignore , Fildlist).
Judging by the documentation, this form is intended for user transformation of table records.
Let's see how it all works. For example, create a table, write data, and then add new fields and transform with ignore: Test: Now we have both types of records in the table and we can read them. But if we now try to create an index on the fourth field of the record , we get a fatal error, stop mnesia. The next time you start this database, an error will occur again. Removing the r1.dcm file will help - after that, mnesia will start. You will also need to remove the table definition from the schema. Therefore, as long as all records in the tables do not comply with the specification of the index, in no case should you index it.
Based on all of the above, it can be argued - the transformation of mnesia tables is quite a serious problem. Apparently, it is necessary to provide, at the design stage, the operating modes of the system for the transformation of tables.
The possibility of functioning in transition mode is also demonstrated, when both new type and old type records are placed in the table. How exactly to complete the transition to a new type of record (get rid of old type records) depends on the specific system.
If anyone is familiar with the problem of changing tables in Mnesia - share it. There is very little information about Mnesia.
When creating a table, you must specify a list of fields. We will not go deep into the recommendation to use a record of the same name with the table. It is important that when changing the list of fields according to the option proposed in the documentation using mnesia: transform_table (converting fields and replacing the table definition), it seems that you will have to stop the system, convert the table, change the application code to work with the new type and start (testing).
If you look at any SQL database, then adding a field is an elementary operation.
It is important for me to switch to a new type without stopping the entire system. At the very least, the database should function continuously.
I researched reading and writing in Mnesia. And the conclusion is:
Mnesia tightly controls the data during recording. You can write only what is declared in the table structure, otherwise an error. The name of the record and the number of elements is controlled - i.e. ALL.
However, when reading, Mnesia gives away what was written, without checking the current configured list of fields and the name of the record. And the list of fields can be changed without actually transforming records using the not recommended mnesia form: transform_table (Tab, ignore , Fildlist).
Judging by the documentation, this form is intended for user transformation of table records.
Let's see how it all works. For example, create a table, write data, and then add new fields and transform with ignore: Test: Now we have both types of records in the table and we can read them. But if we now try to create an index on the fourth field of the record , we get a fatal error, stop mnesia. The next time you start this database, an error will occur again. Removing the r1.dcm file will help - after that, mnesia will start. You will also need to remove the table definition from the schema. Therefore, as long as all records in the tables do not comply with the specification of the index, in no case should you index it.
-module(recordtest).
-compile(export_all).
-record(r1 ,{f1,f2}).
-record(r2 ,{f1,f2,f3,f4}).
dbtest()->
mnesia:create_table(r1,[{attributes, record_info(fields, r1)}]).
transform()->
mnesia:transform_table(r1,ignore,record_info(fields, r2), r2).
14> mnesia:create_schema([node()]).
18> mnesia:start().
ok
19> recordtest:dbtest().
{atomic,ok}
20> mnesia:dirty_write(r1, {r1,l1,l2}).
ok
21> mnesia:dirty_write(r1, {r1,t1,t2,t3}).
** exception exit: {aborted,{bad_type,{r1,t1,t2,t3}}}
in function mnesia:abort/1
22> mnesia:dirty_write(r1, {r2,l1,l2}).
** exception exit: {aborted,{bad_type,{r2,l1,l2}}}
in function mnesia:abort/1
23> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
24> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
38> recordtest:transform().
{atomic,ok}
39> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
40> mnesia:dirty_write(r1, {r2,l1,l2}).
** exception exit: {aborted,{bad_type,{r2,l1,l2}}}
in function mnesia:abort/1
41> mnesia:dirty_write(r1, {r2,a1,a2,a3,a4}).
ok
49> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
50> mnesia:dirty_read(r1, a1).
[{r2,a1,a2,a3,a4}]
mnesia:add_table_index(r1,[l4]).
Based on all of the above, it can be argued - the transformation of mnesia tables is quite a serious problem. Apparently, it is necessary to provide, at the design stage, the operating modes of the system for the transformation of tables.
The possibility of functioning in transition mode is also demonstrated, when both new type and old type records are placed in the table. How exactly to complete the transition to a new type of record (get rid of old type records) depends on the specific system.
If anyone is familiar with the problem of changing tables in Mnesia - share it. There is very little information about Mnesia.