Comment I made in a Support Case:
The column has a limitation so that String variables can be stored in a VARCHAR-type column. This was a conscious design choice and it was made for the following reasons:
- Data access: when a String variable is accessed, the value is eagerly fetched. This way no additional roundtrip is needed to the database for fetching the value. This is desirable if the value is reasonably small but undesirable if it is too big.
- Queries: querying these variables is reasonably fast since the database can index them more efficiently.
As a user, if you want to store a text value in the process engine, you have two options:
- Small(er) text values of limited size can be stored as String type variable and will end up in this column. You can adjust the size of the column to you individual needs.
- Larger text values of arbitrary size can be stored as Binary (Blob) and will be stored in another column.
The engine could of course make this transparent, providing a single API over the two types (if strings get too long, they are simply stored differently underneath). However, we explicitly decided against that.
- We feel that it would be a very leaky abstraction; we prefer that as a user you need to make this tradeoff consciously: am I using a String which gives me simplicity and performance but I need to live with the max-size limitation or am I using an arbitrary size value but now I need to live with the performance implications?
- The mutating operations (adding, changing, removing variables) are one thing, but the queries are another: queries by string variable value would now always need to both query the VARCHAR column AND some arbitrary size BLOG / CLOB column which would make things a lot less performant.