Breaking changes

DB product feature changes that create incompatibilities with previous versions

Version	Description	Recommendations
13.1.0	By default, when JSON DB creates tables, it now uses a padding character of 32 and a field delimiter of 32. It also returns CHAR fields as fixed-length, space-padded strings. These changes were made to promote compatibility with SQL. Previously, JSON DB did not define how fixed-length strings were padded, and defaulted to using NULL (0x00) characters for padding and field delimiters.	If this is not your desired behavior, you can change it using the “padValue” and "fieldDelimiterValue" properties upon table creation, and the "fixedLengthCharFormat" property when querying data from a table.
13.1.0	Prior versions of the server configuration file, ctsrvr.set, are not compatible with 13.1.0.	Regenerate ctsrvr.set using the ctcfgset utility.
13.1.0	In JSON DB, each index created now has its own file. Previously, multiple created indexes would typically share the same index file. SQL is not impacted; it still creates one file on disk for each index, like before.	No action is required, except to be aware of the changed behavior.
13.1.0	13.1 adds support for passwords longer than 64 bytes. If your Faircom client supports and uses passwords longer than 64 bytes, but your FairCom server does not (or vice versa), then LDAP authentication will break.	If you use LDAP authentication, update both clients and servers together, not just one or the other. Customers who have compiled older versions of the client library into their applications must upgrade to the new client libraries or ensure their applications use passwords that are 64 bytes or less.
13.1.0	By default, JSON DB is now required to honor the NULL constraints on non-nullable fields. This prevents users from setting a null value in a non-nullable column.	You can toggle this behavior using the new CTDB_BEHAVE_CHECK_NULL_CONSTRAINT item in ctdbsetbehavior.
13.1.0	FairCom clients and servers now support configurable password hash algorithms (such as PBKDF2) and scalable password hash difficulty. This strengthens the hashing algorithm we use to store passwords in the database, making password-based authentication more secure against offline brute force attacks. This change affects all ISAM and SQL clients. This change can become breaking if you turn on password hash support using PASSWORD_HASH without using a client that supports the hash algorithm configured by the server. To support this change, we now automatically upgrade older versions of FAIRCOM.FCS at startup. Thus, FAIRCOM.FCS cannot be downgraded for use with prior server versions.	If you do not wish to use scalable difficulty hash algorithms, leave PASSWORD_HASH set to its default value of ORIGINAL. If you wish to use them, use a client that supports the hash algorithm you want to configure. See PASSWORD_HASH for more details. The change to FAIRCOM.FCS will not cause problems as long as you back it up before upgrading, as should be standard practice.
13.0.3	ctChecklock is now enabled on all files by default, so we do not allow a connection to update a record if it has not been locked (the attempt will fail with error 57). This safeguards against potential crashes/hangs when freeing unclaimed locks.	If you wish to restore the old behavior of allowing updates on records that are not locked, set AUTO_CHECKLOCK to NO.
13.0.3	Previously, when using ctdbSetBatchFilter to add a record filter to a batch, the filter could be applied to other record handles you used while the batch was active. Now, the filter will apply only to the record that the batch refers to.	If you relied on the old behavior, please contact FairCom Support.

disruptions modifications

Was this article helpful?

Give feedback about this article