Skip to content
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

Selecting from a table immediately out of a create table transaction #184

Closed
ghominejad opened this issue Feb 19, 2015 · 8 comments
Closed

Comments

@ghominejad
Copy link

After creating a table i must wait a few milliseconds until transaction done otherwise i can't use db tables out of this transaction.

db.init(); // makes db schema if not exist
db.checkSomething(); // i use a table and encounter with txLock error

Transaction error :
"db":{"openargs":{"name":"mydb"},"dbname":"mydb"},"txlock":true,"readOnly":false,"executes":[]}
I think a sync transaction is very useful.

db.transactionSync(function(){
    db.executeSql('CREATE TABLE IF NOT EXISTS tbl_settings (key text primary key, data blob)'); 
});

Then we can use async transactions immediately after that :

db.transaction(function(tx){
    tx.executeSql('select data from tbl_settings....')
});
@ghominejad ghominejad changed the title txLock error Out of a create table transaction i need to use the table immediately in other transaction Feb 19, 2015
@ghominejad ghominejad changed the title Out of a create table transaction i need to use the table immediately in other transaction Selecting from a table immediately out of a create table transaction Feb 19, 2015
@ghominejad
Copy link
Author

exec function waits until initialization is done. also using queries is simpler via exec function

    var ready = false;

    function exec(command, vals, callback, errCallback) {
        if (Object.prototype.toString.call(vals) === "[object Function]") {
            errCallback = callback;
            callback = vals;
            vals = undefined;
        }

        if (!ready) {
            setTimeout(function (){
                exec(command, vals, callback);
            }, 100);
        } else  {
            db.transaction(function (tx) {
                tx.executeSql(command, vals, callback);
            }, errCallback);    
        }
    }

    function dbInit() {
        db = openDatabase();
        db.transaction(function (tx) {
            db.executeSql('CREATE TABLE IF NOT EXISTS tbl_settings (key text primary key, data text)'); 
            ready = true;
        });
    }

    dbInit();
    // here we can't use tbl_settings via db.transaction

    // exec waits until create table transaction is done
    exec('select * from tbl_settings where key like ?;', ['key1'], function (tx, res) {
        // callback(null, res.rows);
    });

@brodybits
Copy link
Contributor

The right thing to do workaround is: wait for the success callback from the sqlitePlugin.openDatabase function. This needs to be documented. Whether or not this issue shows up is due to timing.

@brodybits
Copy link
Contributor

This issue also shows a deviation from how the Web SQL API works. The CoffeeScript/Javascript should be updated to wait until the database is actually opened before attempting to post the transaction.

@brodybits
Copy link
Contributor

To fix this issue in CoffeeScript/Javascript will take some restructuring. I am planning to work on this in the next 1-2 weeks or so.

@ghominejad
Copy link
Author

Thank you very much, but what about ddl queries (create/alter, ...)? after database ready we have to wait until these queries become complete. i think its good idea we have two type of commands, first ddl commands that are executed normal and other queries that should honor ddl commands completion.

function onDatabaseOpened() {
     if (!isDatabaseConfigured) {
         executeSql('create table...'); // this is ddl command and runs as normal
     }
}
// other section of the app that runs on application startup
executeSql('select * from ...'); // a ddl command is running so this should wait until ddl command is done

@brodybits
Copy link
Contributor

Thank you very much, but what about ddl queries (create/alter, ...)? after
database ready we have to wait until these queries become complete. i think
its good idea we have two type of commands, first ddl commands that are
executed normal and other queries that should honor ddl commands

@ghominejad it is a nice idea but I would not bother with it.

My idea is that all db operations should be queued until it is possible to execute them.

It should just work, like it does when you open a normal Web SQL database!

@ghominejad
Copy link
Author

yes, you're right, its better idea :)
thank you

brodybits pushed a commit that referenced this issue Mar 17, 2015
Discovered this while working on a solution for #184 & #209.

Minor cleanup of comments.
brodybits pushed a commit that referenced this issue Mar 18, 2015
Clean separation between SQL tests (which should apply to both Web SQL and this plugin) and plugin-specific tests.

Add reproduction of minor bug #204.

Move reproduction of #209 to section with plugin-specific tests.

Mark some plugin db tests that were added by Mark Oppenheim (mailto:mark.oppenheim@mnetics.co.uk) as "Needed to support some large-scale applications".

Test repeatedly open and close db two ways (whether or not to wait for open callback before closing db)

Add another test of repeatedly open and delete db (wait for open callback before deleting db)

Needed for #184/#204/#209/#210/#211/#213.
brodybits pushed a commit that referenced this issue Mar 18, 2015
…ase that is being opened (#184).

Document related txLocks & openDBs map objects.

Mark other bugs to be fixed (#204/#209/#210).
brodybits pushed a commit that referenced this issue Mar 18, 2015
CHANGES:
- Use per-db state to properly handle transactions requested on a database that is being opened (#184).
- Report an error upon attempt to close database multiple times.

TEST:
- Reproduce BUGs #204/#209
- Expand some existing scenarios
- Prepare test suite for upcoming fixes and improvements (#184/#204/#209/#210/#211/#213)
brodybits pushed a commit that referenced this issue Mar 18, 2015
CHANGES:
- Use per-db state to properly handle transactions requested on a database that is being opened (#184).
- Report an error upon attempt to close database multiple times.

TEST:
- Reproduce BUGs #204/#209
- Expand some existing scenarios
- Prepare test suite for upcoming fixes and improvements (#184/#204/#209/#210/#211/#213)
@brodybits
Copy link
Contributor

Hi @ghominejad I have now pushed a quick fix to the master branch. Can you give it a try, if you have a chance, and let me know whether or not it solves your issue?

I am planning to restructure the CoffeeScript/Javascript to solve some more issues with managing the internal state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants