-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Whether to keep separate cordova-sqlite-ext version or not? #529
Comments
Hi, |
I just found https://www.thepolyglotdeveloper.com/2016/08/using-sqlstorage-instead-sqlite-ionic-2-app/#comment-2830426951:
I did NOT mean that the cordova-sqlite-ext plugin would disappear in favor of using a database dump or JSON file. The other plugin was actually created to support the case where it is really needed and will not go away as long as there is a need for it. At the moment I would favor an idea where this plugin would be used along with an external utility plugin to provide the same functionality for those who need it, kind of like cordova-plugin-dbcopy but better tested and more intuitive. |
Ah ok sorry for the misunderstanding. |
Another idea under consideration would be to include the SQLite3 dependencies in cordova-sqlite-ext as a solution to #477. ADDITIONAL NOTE: This is a side comment. It is NOT related to the issue with pre-populated databases under discussion here. |
Some updates: From discussions in danielsogl/awesome-cordova-plugins#881 & storesafe/cordova-sqlite-storage-help#26 I have identified a desire for a pure-JavaScript solution for pre-populated databases, with further discussion in #683. In case I find a solution to #683 the |
Changed my mind: I am now planning to issue a new release with this plugin version combined with cordova-sqlite-ext. One less plugin version to test and support; less risk of developers using invalid combination of cordova-sqlite-storage and cordova-sqlite-ext plugin versions (#719). |
@brodybits Any update on when the merged release of cordova-sqlite-storage and cordova-sqlite-ext will be available? README still states September. |
Now planned for December 2018, about to update README.md |
Hello, Is this really inserted in the latest versions of cordova-sqlite-storage? Where can I find an example for bd pre-populate with this plugin and not sqlit-ext? |
Changed my mind (yet) again, my apologies. I will likely keep the separate plugin versions for now. I am hoping to make a more flexible redesign as discussed in #862. |
Initial question on Twitter
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>My response on Twitter
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>Further discussion on Twitter
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>Background: what is added in cordova-sqlite-ext?
Further response
I would like to keep the separate cordova-sqlite-ext version for the following reasons:
Why I do not favor pre-populated databases
Pre-populated databases add complexity and need more storage space. It may be possible to free some storage space by deleting the original pre-populated database but it would not work if someone wants to delete all changes and start over.
I would favor a solution where the app fetches the data upon startup. The data may be in a format such a database dump, JSON, compressed database, or whatever else. If a user wants to erase all changes and start again, this should really be straightforward.
An exception may be an organization-specific application where they want to install an app on the employees' devices without the extra step of downloading the data. But this could also be solved by using something like a database dump or JSON file.
Finally, there are alternatives such as using cordova-plugin-dbcopy or cordova-plugin-file (though they may be a little tricky to use correctly). For example the cordova-sqlite-plugin-2 documentation describes how to achieve this using cordova-plugin-file.
Could this be done better?
I have seen some others voice confusion about the proliferation of different plugin versions. To be honest, it does cost me quite a bit of time to maintain the different plugin versions. I generally merge the changes from this version into the others then resolve conflicts. I spend the most time testing and retesting different plugin versions and maintaining the documentation.
I can think of the following alternatives to support pre-populated databases:
It would also be possible to change the SQLCipher version to include the implementation of this version as a dependency. Unfortunately it would be very difficult for the evcore and other "enterprise" versions to benefit this way due to the differences in implementation.
P.S. This discussion is open for comments. I cannot promise when I would have a chance to implement any of the possible improvements discussed here due to my current backlog.
The text was updated successfully, but these errors were encountered: