The JADE 2022 release meets tomorrow’s business demands.
John Munro
|
HistoricalComments
John Beaufoy 11/10/2017 3:26:16 PM
Had a similar problem - built a VariableStringArray class that utilises a JadeBytes structure with an array to record offsets for each index. If you track me down @ NWI I'd be happy to forward on the code. I should stress that this solution is less than ideal - effectively a hack - so having an inbuilt solution would be cleaner, more accessible and more performant. |
All instances of arrays of Binary, String and StringUtf8 will have a new internal format. Collection blocks are smaller, resulting in improved performance, reduced object cache footprint and database file size. The bound on the maximum length of entries in the Array classes BinaryArray, StringArray and StringUtf8Array will be increased to the upper bound for the membership of the array: BinaryArray from 128 to 16000 Bytes, StringArray from 62 to 15999 Characters, HugeStringArray from 2047 to 15999 Characters and StringUtf8Array from 30 to 8000 StringUtf8 Characters. HugeStringArray effectively becomes an alias for StringArray. The upper bound on user defined Array subclasses will not be changed. When the database is upgraded from 2018 any persistent instances will be converted to the new format. No application changes will be required to take advantage of the improvements with the new implementation.
What are the trade-offs of converting uses of fixed-length string arrays like HugeStringArray to the new type? I'm thinking that most uses have a large number of small strings but use, say, HugeStringArray to cater for odd cases. Is there a formula for the persistent storage requirements for old and new string arrays? Is the performance roughly the same?