1.3.4
Compatibility
Changes
CeraEconomy 1.3.4 — Changelog
✨ Added
- Added SQLite storage support.
- Added SQLite ".db" based economy storage.
- Added support for 6-way storage migration:
- YAML → MySQL
- MySQL → YAML
- YAML → SQLite
- SQLite → YAML
- MySQL → SQLite
- SQLite → MySQL
- Added migration configuration options:
- "yaml-to-mysql.enabled"
- "mysql-to-yaml.enabled"
- "yaml-to-sqlite.enabled"
- "sqlite-to-yaml.enabled"
- "mysql-to-sqlite.enabled"
- "sqlite-to-mysql.enabled"
- Added automatic disabling of migration flags after a successful migration.
- Added SQLite support to the common "Storage" abstraction.
🔧 Improved
- Improved storage management through "StorageManager".
- Economy operations now work consistently across YAML, MySQL and SQLite.
- Added SQLite account and player-name handling.
- Added SQLite migration handling for existing YAML/MySQL economy data.
- Improved migration logging and error handling.
- Fixed migration-related compilation issues.
🐛 Fixed
- Fixed invalid multi-catch usage involving "IllegalArgumentException" and "NumberFormatException".
- Fixed missing MySQL account import functionality required by SQLite → MySQL migration.
- Fixed storage migration data handling.
- Verified player balances are preserved correctly during migrations.
🧪 Tested
All 6 storage migration directions have been tested successfully:
- ✅ YAML → MySQL
- ✅ MySQL → YAML
- ✅ YAML → SQLite
- ✅ SQLite → YAML
- ✅ MySQL → SQLite
- ✅ SQLite → MySQL
Balance data was successfully preserved and transferred between all three storage systems.
⚠️ Known / Pending
- "save-message" configuration is not fully implemented yet.
- SQLite ".db" file location/persistence still needs final verification.
- "reset-per-start" configuration is planned but not fully implemented yet.
📦 Version
CeraEconomy 1.3.4
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:lfNCaCGD:PjUkYi4u"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:lfNCaCGD:PjUkYi4u"
}
