In flowable (and Activity too) every variable in a process has its own type. There are two kinds of types - those which values are saved in act_hi_varist (column text_), and the second type is the long type (table act_ge_bytearray).
I want to avoid converting long values into bytes. I prefer to hold all (even long) values in String/JSON type in act_hi_varist.
To do this I’ve changed the definition of column text_ in table act_hi_varist from VARCHAR(4000) to text (postgres) and I’ve removed all those VariableLongType from flowable-engine configuration.
and it works, but I want to know the idea behind these LongVariables?
I wanted to find it in git history but commit message tells nothing.
The reason for the long string variable type is to be able to support long texts (more than 4000 or 2000 on Oracle). The value of the variable is not always needed. Therefore, from a performance point of view it is better not to transfer the bytes from the DB to the application.
What is the reason that you don’t want to have the long bytes stored in the byte array table?
What is the reason that you don’t want to have the long bytes stored in the byte array table?
In some cases, we want to select those values directly from DB without using flowable (and without Java too). If those variables are stored as bytes, it is difficult.
Is there any particular reason why not to store long strings directly in act_hi_varinst table if DB enables it (Postgres)?
Currently act_hi_varinst table does not have an index on bytearray_id_ column, so to join table act_ge_bytearray efficiently we would need to add an index. We wonder if storing all variables in in act_hi_varinst table would not be better?
As I said earlier, the value of the variable is not always needed. Therefore, from a performance point of view it is better not to transfer the bytes from the DB to the application.
I don’t think that an index is needed on the bytearray_id_ column for the join to be efficient. We are talking about joining when you are selecting in the act_hi_varinst_ table. For the join to be efficient an index is needed in the act_get_bytearray table, and since the join is with the primary key there is already an index on that.
