I think the plugin need a fstat or status function that returns the following about the destination file: 1) whether the file exists in the destination, and 2) the data time created, and 3) the date time last modified.
App initial installation is the simple case, but there are some additional requirements for App update.
Case 1) The database loaded from www initial installation never changes. Once it is copied to the destination we never want to copy it again. The plugin handles this case now.
Case 2) The database loaded from www needs to overwrite the destination database when the App is updated, but we don't want to do this copy each time the App starts. We only want to do it when the App is updated. If we could get the last modified datetime of the destination file we would be able to tell if the copy needed to be done.
The App update situation can become much more complex if a database contains some data that came from the developer and other data that is from the end user. In that case some kind of merge operation has to be done instead of a copy. But it is probably best to simply avoid this case by always putting end user data in a different database than data that comes from the developer.
I think the plugin need a fstat or status function that returns the following about the destination file: 1) whether the file exists in the destination, and 2) the data time created, and 3) the date time last modified.
App initial installation is the simple case, but there are some additional requirements for App update.
Case 1) The database loaded from www initial installation never changes. Once it is copied to the destination we never want to copy it again. The plugin handles this case now. Case 2) The database loaded from www needs to overwrite the destination database when the App is updated, but we don't want to do this copy each time the App starts. We only want to do it when the App is updated. If we could get the last modified datetime of the destination file we would be able to tell if the copy needed to be done.
The App update situation can become much more complex if a database contains some data that came from the developer and other data that is from the end user. In that case some kind of merge operation has to be done instead of a copy. But it is probably best to simply avoid this case by always putting end user data in a different database than data that comes from the developer.