One related and good to have feature is to set a single character encoding by default for the tables when siddhi creates them on the database. The primary key length issue is mostly due to having collations which take more bytes to represent a single character. If we can default to a character encoding of a single byte per character for each database type, then we could avoid these issues. Just a thought.
On Fri, Nov 22, 2019 at 5:31 PM Rukshan Premathunga <[email protected]> wrote: > Hi All, > > When we configure partitionById in SP, siddhi automatically adds > a SHARD_ID column to all the aggregated tables in RDBMS. But we are having > a "too long key issue" in the database. As a solution, we need to properly > set the column length for each attribute in the aggregated event stream. > > Limit of columns in the aggregated streams can be defined when we > implement the siddhi app. But SHARD_ID is used only when partitionById is > configured. So we cannot provide and initial column length for that. > > So it will be an ideal solution for us to have a configuration for this. > Otherwise, users need to alter the database or siddhi applications to > define these values. So can you please check the possibility to support > this? > > ex: > siddhi: > properties: > partitionById: true > shardId: dc1 > shardId_size: 20 # or derive length from 'shardId' > > Thanks and Regards > > -- > Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. > (m) +94711822074 | (w) +94112145345 | Email: [email protected] > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- Thanks & Regards, *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc Mobile : +94772338839 | [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
