Skip to content
v26.3

Database (CouchDB / SQLite / SQL Server)

DiKAS supports three database providers. The provider is configured in appsettings.json (Database.Provider) or via environment variables — the code is identical, all functions are available with every provider.

Provider Use
CouchDb (default) Server/cloud operation, multi-tenant, replication
Sqlite Single workstation, Android app, demo/development
SqlServer Existing Microsoft infrastructure

Configuration

{
  "Database": { "Provider": "CouchDb" },
  "CouchDb": {
    "ServerUrl": "http://localhost:5984",
    "DatabasePrefix": "dikas",
    "MainDatabase": "main"
  }
}

Environment variables override the file — convenient for Docker and tests:

Variable Meaning
Database__Provider CouchDb, Sqlite or SqlServer
COUCHDB_URL Server URL, e.g. http://192.168.1.10:5984
COUCHDB_USER / COUCHDB_PASSWORD Credentials
COUCHDB_PREFIX Database prefix (unique per installation/tenant)

On first start, DiKAS automatically creates the databases ({prefix}_maindb, {prefix}_gastrocurrent), the design document with all views, and — on an empty database — the demo data.

Demo Data and History

  • Auto-seed: An empty database (SQLite or CouchDB) is filled with demo master data on start (articles, staff, tables, customers).
  • Generate history (for tests/evaluations):
dotnet run --project Dikas.Api.Web -- --seed-history 730

generates realistic receipts, shifts, and end-of-day reports for the specified number of days (bulk write rate ≈ 760 documents/s). Receipt/shift/report numbers are continued, and ongoing operation connects seamlessly.

Performance (CouchDB)

The most important adjustment levers from the load test with 2 years of history (34,500 receipts):

  • Date range instead of full scan: All reports and operational queries load receipts via the bybizdate_docs view (business-day range). Short periods are thus fast regardless of the database size.
  • Pre-aggregated daily revenues: The map/reduce view revenue_daily sums up gross/tax/receipt count per day directly in CouchDB. The endpoint GET /api/v1/reports/daily-aggregate?startDate=…&endDate=… delivers 2 years of daily revenues in ~0.1 s — ideal for dashboards.
  • Slow query log: View accesses over 1 s appear as a warning in the log (view, row count, duration, URL) and reveal expensive queries immediately.
  • Maintenance: After large data imports, schedule _compact and _view_cleanup — the document views keep a copy of the receipts in the index (storage for speed).

Cloud Synchronization

Local installations can synchronize with the central cloud CouchDB. The connection is resolved automatically from the license (systemlic) at server start: user = SyncLink (lowercase), password = SyncLink, remote database = {DatabaseName}_{db}. A manually filled Sync section in appsettings.json overrides the license. Management and status: Admin → Settings → System → Cloud sync (support login).

Mode Mechanism
CouchDb (local) Native CouchDB replication: continuous push+pull entries in _replicator for {prefix}_maindb and {prefix}_gastrocurrent (ID pattern {prefix}_{db}_push / _pull)
Sqlite / SqlServer Own sync service: push/pull of selected document types at intervals (conflicts: last-write-wins)
Cloud multi-tenant No synchronization — devices work directly on the central database

When setting up native replication, outdated _replicator entries are removed that point to the same databases but no longer match the current configuration (e.g., after a change of SyncLink or database name). If the SyncLink is missing from the license, the own entries are deleted — replication is then disabled. The job status (_scheduler/docs) is displayed on the cloud sync page; in case of connection errors, the server retries the setup every 5 minutes.

SQLite Notes

  • Database file: Dikas.Api.Web/dikas.db (in the content root, independent of the working directory).
  • Schema migrations run automatically on start (EF Core).
  • For migration to CouchDB: create a backup and restore it into a CouchDB installation (see Backup & Restore).