matejbart / DocScan

GNU Lesser General Public License v3.0
2 stars 0 forks source link

data migration (android room) #1

Open matejbart opened 3 years ago

matejbart commented 3 years ago

The main task is to migrate the existing json data into an android room database, some main reasons of performing this task:

The migration steps:

Some general open questions that are unanswered:

  1. What happens with the document, if an upload has succeeded? Can it be uploaded twice or should this be restricted?
  2. After a successful upload, should it be possible to add new images and re-upload the same document again?
  3. Is it ok, to "lock" the document until the images are uploaded? This would probably prevent some weird states, where a big upload is ongoing and the user starts to delete/modify or add new images.
  4. If the user would logout and then re-login (let's assume with another account) should the document/data be still marked as uploaded?
  5. Is it ok to drop the currently unused isFocused flag for pages/document?
  6. Is there anything else to maybe also consider at the migration? (Like adding new fields for e.g. using a new API)
  7. Is there any specific reason why some image related data has been saved in the image file itself and not in the json? Like the cropping points etc. Would it be ok to move this into the DB? And if necessary, incorporate it into the files only for the export?
  8. As already mentioned, the bottom navigation is maybe not the best approach for the document viewer, because those fragments should be independent (data) from each other. However, the images fragment always depends on the selection of the document which is shown before - there will be always the problem when the active document is deleted and then the user navigates to the images fragment in the bottom nav. Is there maybe a possibility to re-work this?
    • I could imagine to use only two bottom nav fragments, documents and exports (currently PDFs), when the user selects a document, the images fragment will be hierarchly shown in a new activity.
    • The navigation drawer could be also dropped, and maybe replaced by a third fragment called "More" where everything else is listed. The drawer from the camera activity is not really necessary, because the document viewer can be still accessed and the settings could be extended so that every previous use-case is covered.
hollaus commented 3 years ago

Thanks! The migration plans sound plausible and I think we should discuss them in a meeting. I have answered your general questions inline:

Some general open questions that are unanswered:

1. What happens with the document, if an upload has succeeded? Can it be uploaded twice or should this be restricted?

No, I think we should prevent a duplicate upload.

  1. After a successful upload, should it be possible to add new images and re-upload the same document again? Yes, it should be possible to re-upload the document again.
  2. Is it ok, to "lock" the document until the images are uploaded? This would probably prevent some weird states, where a big upload is ongoing and the user starts to delete/modify or add new images. I guess it is OK, but then it should be possible to cancel the current upload, because otherwise the user cannot take new pictures until a big upload is finished.
  3. If the user would logout and then re-login (let's assume with another account) should the document/data be still marked as uploaded? I think it would be better to clear then the upload information and it should be marked as not uploaded.
  4. Is it ok to drop the currently unused isFocused flag for pages/document? Definitely, this is legacy code.
  5. Is there anything else to maybe also consider at the migration? (Like adding new fields for e.g. using a new API) I do not think so.
  6. Is there any specific reason why some image related data has been saved in the image file itself and not in the json? Like the cropping points etc. Would it be ok to move this into the DB? And if necessary, incorporate it into the files only for the export? The reason is that we wanted to make this data also usable in Transkribus, but it has not been used there. So basically it is OK. However, I would always save Exif orientation in the images itself and not in the DB, because otherwise the images will not be rotated correctly in other applications (image viewers, Transkribus).
  7. As already mentioned, the bottom navigation is maybe not the best approach for the document viewer, because those fragments should be independent (data) from each other. However, the images fragment always depends on the selection of the document which is shown before - there will be always the problem when the active document is deleted and then the user navigates to the images fragment in the bottom nav. Is there maybe a possibility to re-work this?

    • I could imagine to use only two bottom nav fragments, documents and exports (currently PDFs), when the user selects a document, the images fragment will be hierarchly shown in a new activity.
    • The navigation drawer could be also dropped, and maybe replaced by a third fragment called "More" where everything else is listed. The drawer from the camera activity is not really necessary, because the document viewer can be still accessed and the settings could be extended so that every previous use-case is covered. It is possible yes, but I think this should be done at a future point.