[FEATURE] - Support for "local" version (offline)

[cedricfrancoys]

Database Usage Strategy

Remote Database as Primary

• The application will primarily use the remote database for all operations.
• If the connection to the remote database is unavailable, the application will fallback to a local database to ensure continuity.

Synchronization Actions Between Local and Remote Databases

Synchronization Features

1. Selective Synchronization:

   • The system should allow limiting synchronization to specific entities or data sets. This provides control over which data is synced to reduce overhead and improve efficiency.

2. Export Local Changes:

   • Local changes made while the application is offline should be exportable to the remote database once connectivity is restored.
   • This includes:
     • Uploading Local Records: Changes or new records created locally are sent to the remote database.
     • Local Cleanup: Once local records are successfully exported and validated, they are removed from the local database to prevent duplication.

Managing Offline Records

Identification of Local Records

• Local records can be identified using a dedicated field, such as offline.
• The offline field works similarly to a deleted flag, marking records created or modified offline. These records will remain in the local database until they are synchronized with the remote database.

Example: Offline Field Usage

• The offline field can be a boolean (true for offline records, false for synced records) and will be updated as part of the synchronization process.

{
  "id": 1,
  "name": "Sample Data",
  "offline": true
}

• Once the record is synced with the remote database, the offline field will be set to false or removed, indicating successful synchronization.

Pros & Cons

Advantages

• Offline Access: The application can be used even without an active internet connection.

Disadvantages

• Update Complexity: Updating the application requires either local access or downloading a new version, which can be less convenient.