> For the complete documentation index, see [llms.txt](https://daddy-studios.gitbook.io/daddy-studios-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://daddy-studios.gitbook.io/daddy-studios-docs/scripts/daddy-marketplace/database.md). # Database Daddy Marketplace uses `oxmysql`. There is **no SQL file to import** — every table is created on the first start, and databases created by an earlier version are migrated automatically (missing columns are added, the offer status enum is widened). A successful start prints: ``` [Daddy Marketplace] Database ready. ``` Supported: MariaDB 10.3+ and MySQL 5.7+/8. All tables are InnoDB / `utf8mb4`. ## Tables | Table | Holds | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `daddy_marketplace_listings` | Fixed-price listings. `status`: `active`, `sold`, `cancelled`, `expired`. Carries the seller, item, metadata, quantity, unit price, category, location, expiry and the featured flags. | | `daddy_marketplace_auctions` | Auctions. `status`: `active`, `settling`, `ended`, `cancelled`, `no_bids`. Carries the minimum price, buyout, current bid and bidder, bid count and `ends_at`. | | `daddy_marketplace_bids` | Every bid ever placed, for the auction's bid history. | | `daddy_marketplace_offers` | Offers on listings. `status`: `pending`, `accepted`, `rejected`, `expired`, `cancelled`, `countered`. `escrow_held` records whether the buyer's money is currently held. | | `daddy_marketplace_buy_orders` | Buy orders. `remaining` and `remaining_escrow` shrink with each fulfilment, so a partially filled order always knows exactly what is still owed. | | `daddy_marketplace_buy_order_fulfillments` | One row per seller filling (part of) a buy order, with the item metadata and what the seller was paid. `claimed`: `0` waiting, `1` claimed, `2` being claimed right now. | | `daddy_marketplace_pending_deliveries` | The delivery depot: anything that could not be handed over immediately. `source_type` says where it came from (sale, expiry, admin cancel, …). | | `daddy_marketplace_history` | Completed trades, used for price history and the history page. | | `daddy_marketplace_reputation` | Seller ratings. A unique key on `(rater_identifier, transaction_ref)` means one rating per trade. | | `daddy_marketplace_watchlist` | Watched listings per player, for price-drop alerts. | | `daddy_marketplace_notifications` | Notifications for players who were offline when something happened. | ## How state is kept consistent Every operation that moves money or items first claims the row in SQL with a conditional update — for example `UPDATE ... SET status = 'sold' WHERE id = ? AND status = 'active'`. Only the query that actually changed a row is allowed to continue. This is why two players buying the same listing in the same tick cannot both be served, and why an auction cannot settle twice. Anything that cannot be delivered at that moment is written to `daddy_marketplace_pending_deliveries` inside the same flow, so the value always exists somewhere: in an inventory, in escrow, or in the depot. ## Cleanup `Config.HistoryRetentionDays` (default `90`) removes finished records that are older than that many days: * history rows * listings with status `sold`, `cancelled` or `expired` * auctions with status `ended`, `cancelled` or `no_bids` * offers with status `accepted`, `rejected`, `expired` or `cancelled` * delivered rows in the delivery depot (`delivered = 1`) * notifications Open listings, active auctions, unfilled buy orders and **undelivered** depot rows are never removed. Set the option to `0` to keep everything forever. ## Backups Nothing else stores marketplace state, so a dump of these eleven tables is a complete backup. Player money and items live in your framework and inventory as usual. ## Next steps * [Security](/daddy-studios-docs/scripts/daddy-marketplace/configuration/security.md) * [Commands & Permissions](/daddy-studios-docs/scripts/daddy-marketplace/commands-and-permissions.md) — inspecting a player's depot --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://daddy-studios.gitbook.io/daddy-studios-docs/scripts/daddy-marketplace/database.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.