believes that, while LiteCore does check before creating the column, it does not do so holding a lock. The SO post appears to be from a case in which two threads attempt to create the column and one succeeds after the other has checked.
Build couchbase-lite-core-3.3.0-58 contains couchbase-lite-core commit 6c0e685 with commit message: CBL-6131: Race creating the `expiration` column in a collection table (#2160)
CB Robot
January 8, 2025 at 7:16 AM
Build couchbase-lite-cblite-4.0.0-13 contains couchbase-lite-core commit 6c0e685 with commit message: CBL-6131: Race creating the `expiration` column in a collection table (#2160)
CB Robot
January 8, 2025 at 2:25 AM
Build couchbase-lite-log-4.0.0-12 contains couchbase-lite-core commit 6c0e685 with commit message: CBL-6131: Race creating the `expiration` column in a collection table (#2160)
CB Robot
December 4, 2024 at 7:30 PM
Build couchbase-lite-c-4.0.0-8 contains couchbase-lite-core commit 6c0e685 with commit message: : Race creating the `expiration` column in a collection table (#2160)
CB Robot
November 11, 2024 at 6:54 PM
Build couchbase-lite-ios-4.0.0-2 contains couchbase-lite-core commit 6c0e685 with commit message: : Race creating the `expiration` column in a collection table (#2160)
Fixed
Pinned fields
Click on the next to a field label to start pinning.
This StackOverflow post documents what appears to be a race during the "lazy" creation of the expiration column in a Collection table:
https://stackoverflow.com/questions/78666433/duplicate-expiration-column-in-the-couchbase-schema
believes that, while LiteCore does check before creating the column, it does not do so holding a lock. The SO post appears to be from a case in which two threads attempt to create the column and one succeeds after the other has checked.