DaisyVotes — Storage & Data

DaisyVotes stores all of its data through Sculk Data, the framework’s ORM. The default backend is SQLite, written to a database file inside plugins/DaisyVotes/ — there is no external database to install or configure.

storage.yml

# Managed by Sculk Data. The default is SQLite stored in the plugin folder.
# Only change this if you know what you're doing.

Note

SQLite is the right choice for the vast majority of servers — it’s fast, file-based, and zero-maintenance. For a multi-server network, use a shared MySQL/MariaDB database instead (below).

Multi-server (shared database)

Running DaisyVotes across a network of servers? Point every server at the same MySQL/MariaDB database in storage.yml instead of SQLite. That one shared database keeps vote counts, points, streaks, and the reward queue consistent everywhere — it’s the foundation a cross-server network is built on. Add Redis on top only if you want instant cross-server delivery and parties.

Caution

SQLite is single-server only. A network must use a shared MySQL/MariaDB database — never point multiple servers at one SQLite file.

What’s stored

DaisyVotes keeps its data in a set of tables, created automatically on first run:

Table	Holds
vote_players	Per-player stats: total/daily/weekly/monthly votes, current & best streak, points & lifetime points, streak freezes, parties contributed, first/last vote timestamps.
vote_sites	Per-site totals.
player_site_votes	Per-player, per-site vote counts (drives cooldowns and the daily wheel set).
vote_events	An immutable history of every vote received (used for accurate period windows).
pending_rewards	Rewards queued for offline players, claimed with /vote claim.
vote_party_state	The global vote-party counter and party history.
wheel_states	Per-player available & lifetime wheel spins.
wheel_spins	History of wheel results.
shop_purchases	Purchase history, used to enforce daily limits.
top_voter_state	Tracks daily/weekly/monthly period rollovers.
migration_state	Records which data migrations have been applied.

Tip

Everything is written asynchronously — vote processing starts off the main thread before touching the database, and only returns to the main thread for player-safe actions like giving items. The plugin stores UUIDs and names, never long-lived player references.

Backups

The database is a normal file. To back it up safely:

1. Stop the server (so nothing is mid-write).
2. Copy the database file (and, if you like, the whole plugins/DaisyVotes/ folder) somewhere safe.
3. Start the server.

• Directoryplugins/DaisyVotes/

  • config.yml
  • menus.yml
  • rewards.yml
  • shop.yml
  • storage.yml
  • … the SQLite database file (back this up)

Resetting data

To wipe all vote data and start fresh, stop the server and delete the database file; DaisyVotes recreates it empty on the next start.

Danger

Deleting the database removes all vote counts, streaks, points, and history permanently. Back it up first.

Performance & caching

• Leaderboards are cached for stats.leaderboard-cache-seconds (default 60s).
• PlaceholderAPI values are cached for ~10 seconds so placeholder lookups never hit the database on the main thread.
• Duplicate votes within sites.duplicate-window-seconds are dropped before any write.