Content Comparison

Connect to the datasource

Users configure the connection from the app to the external datasource.

1. What type of datasource is it? (SQL, Posgres, Oracle, MSSQL)

2. Which source will be the primary? Database or App?

1. Support all of them

2. Suggest “Database” to be the main source

Display data from the datasource

Data from the datasource is displayed in tables within the app.

1. Is there a limit to the number of records displayed?

2. How to handle with big data from database?

1. Status
   colour Blue title TBD

2. Status
   colour Blue title TBD

1. No

2. Still run, just take more time to synchonize.

Update data in the app

Users can update data in the app, and the changes are reflected in the external datasource.

1. How should conflicts between app and datasource data be resolved?

2. How can we detect the data as conflict? Should users be notified about unsynced data? Should a warning display for stale data?

3. What happen when the connection is lost? Can still user be able to use that grid?

4. How should conflicts be handled if datasource changes during editing?

5. If the data is add from UI but the database is offline, will the data from app be save or throw error?

1. If the data is not the same, the grid will still show the data (which is saved from Jira database). But in this case, user will not know if the data is not synchonize.

2. Status
   colour Blue title TBD

   We need to find a way to let user know if the data is not the same…

3. When the connection is lost, the user can still use the grid, but the data will no longer sync with the database.

4. The action that is saved last will determine the final data value.

5. Throw error → tested on Data Mirror TGNG

Update data in the datasource

Updates made in the datasource are synchronized back to the app.

1. Is real-time synchronization required, or will periodic updates suffice, or when user reload the grid?

2. How will the app handle partial updates or missing fields?

3. What happens if a record is updated in the app and datasource simultaneously?

4. Should updates from the datasource queue when the user is offline and apply later?

1. Realtime is needed, and user can synchonize again when click on a button “Re-synchonize”.

2. Follow TGE, with the column is not the same type or missing, it will be ignored.

3. The action that is saved last will determine the final data value.

4. Status
   colour Blue title TBD

   A background function to run the synchonize is an option, but not sure if we should support this or not…

Synchronize datasource schema

Automatically detect and adapt to the structure (schema) of the datasource for compatibility.

1. Should the schema be fetched dynamically or provided manually?

2. How will changes in the datasource schema be handled?

3. Should users be notified if new columns or tables are added to the datasource?

4. How to handle if app and database have different restriction? Like allow null value, different in data type?

1. Status
   colour Blue title TBD

   not sure if we supoprt this

2. Status
   colour Blue title TBD

   not sure if we support this

3. No, refect to TGE

4. User will need to synchonize manually

5. Status
   colour Blue title TBD

6. Showing error when user saves data in the app is the option I suggest.

Error handling and notifications

Users are informed of connection issues, synchronization errors, or invalid data.

1. What types of errors should trigger notifications?

2. Should there be retry mechanisms for failed synchonize or connections?

3. What level of detail should be provided in error messages?

1. Status
   colour Blue title TBD

   Errors related to the table structure not the same, synchonize action failed

2. Yes, we should provide a button for users to proactively synchronize. However, we will notify them that all current data will be overwritten by the data from the database. Since the synchronization process might take some time, we need to warn users not to interact with the grid during this period. Additionally, consider providing a progress indicator to enhance the user experience.

3. Status
   colour Blue title TBD

   Show them clearly which column type is preventing user from saving the data.

Security and access control

Ensure that only authorized users can access and update data.

1. What roles/permissions are needed for accessing and updating data?

2. Is encryption required for data in transit and at rest?

3. Should users' actions (e.g., edits, deletions) be restricted based on their roles?

1. User that can edit grid can do this, or admin can use the Grid Behaviour to restrict

Logging and audit trail

Log all actions related to data synchronization for troubleshooting and auditing purposes.

1. What details should be logged (e.g., timestamp, user, action)?

2. Who should have access to the logs?

3. Should there be a UI for viewing logs within the app?

1. Status
   colour Blue title TBD

   Something the same as Grid History should be logged.

2. Admin

3. Yes, but in the Grid Configuration → Data Mirror section for only admin

Data transformation and mapping

Define how the datasource data is mapped to the app's data structure.

1. What if the column type is being changed from one side, what should be happen?

2. How will unsupported or invalid data be handled?

1. With TGE, it does not support changing column types and reflecting those changes in the database and vice versa, if the changes is being processed, the data in table will be broken and does not display the data. TGNG should have the same restriction.

2. Ignore and only work with correct data