brodycj
commented
9 years ago If I understand correctly, using window.openDatabase() will cause the database to be opened/ created in the WebSQL space within the browser with the restrictions inherent to that, rather than as a "normal" SQLite database in the app's data folder.
Yes that is correct.
is there a way to use the plugin but with the window.openDatabase() call, thus enabling queries like the one in this example to work on iOS against a SQLite database?
One of the philosophies of this plugin is that it is by replacing window.openDatabase() with window.sqlitePlugin.openDatabase() that you store your data in the local document or database directory (depending on which platform) instead of the browser's local storage. This is the classic factory pattern.
You could very easily add some code like window.openDatabase = window.sqlitePlugin.openDatabase if you want to use existing WebSQL code with the plugin touching it at all. This is only recommended for extreme cases where you cannot adapt an existing library to replace window.openDatabase() with window.sqlitePlugin.openDatabase() for some reason.
I plan to clarify these points in the documentation when I get a chance.
On the sample "Sample with transaction-level nesting" in the documentation, it mentions at the end "This case will also works with Safari (WebKit), assuming you replace window.sqlitePlugin.openDatabase with window.openDatabase".
If I understand correctly, using window.openDatabase() will cause the database to be opened/ created in the WebSQL space within the browser with the restrictions inherent to that, rather than as a "normal" SQLite database in the app's data folder. Is this correct, or is there a way to use the plugin but with the window.openDatabase() call, thus enabling queries like the one in this example to work on iOS against a SQLite database?