mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
db-migration-test failed on all three upgrade fixtures (v2.0.0, v2.5.0, v2.10.0) with: Column "ULS1_0.SERVER_QUANTITY" not found. ddl-auto=update cannot add a NOT NULL column to a table that already holds rows, and user_license_settings always does - it is a singleton created at first boot. Hibernate logs the failed ALTER and carries on, so the column never exists and the next SELECT blows up. Every upgrading installation would have hit this, not just the fixtures. server_quantity and user_block_size are display-only; the enforced limit is licenseMaxUsers, which is unchanged. They do not need to be in the database at all. ApplicationProperties.Premium already holds them, repopulated on every licence verification - at boot and on the weekly refresh - so the admin payload can read them straight off the verified licence. That removes the schema change entirely rather than working around it with a column default, which is the smaller and safer fix. Also resets the breakdown at the top of verifyLicense. Without persistence the values live only in memory, so removing or invalidating a licence would otherwise leave the previous server count there and the UI would keep reporting capacity the installation no longer has.