Issue with clobber false

[Brett Coffin]

Hi, I am using your dev branch and I am trying to make it work with clobber: false.

ngDb.addSchema("Departement", EntityModel.Departement.dataTypes);

            ngDb.addMigration({ actions: [

                new JohoDB.MigrationAction("add_table", {"tableName": "Departement"}),
                new JohoDB.MigrationAction("add_column", {"tableName": "Departement", "columnName": "id", "columnTraits": {"type": "integer", "primaryKey": true}}),
                new JohoDB.MigrationAction("add_column", {"tableName": "Departement", "columnName": "nom", "columnTraits": {"type": "string"}}),
                new JohoDB.MigrationAction("add_column", {"tableName": "Departement", "columnName": "date_maj", "columnTraits": {"type": "date"}})


            ngDb.init({storageType: JohoDB.WebSQLStorage, clobber: false});

but it doesn't appear to create the table, it works though with clobber true... I know its a work in progress but any pointers would be appreciated thanks and good job.

[James Rakich]

It should work with Clobber unset. Update to npm version 0.4.0 if you haven't already, as I resolved some issues with WebSQL migration in that release. I'll be able to have a proper look in 8 hours if that doesn't help. Also, anything showing up in the console?

[Brett Coffin]

Hey James thanks for the feedback, I got it working finally, It was due to the state of my webSql db, It was lost in migration updates, after deleting and starting fresh it worked :)

[James Rakich]

Cheers Brett, it can be a little tricky working with the state of the database, if it gets caught in limbo things can get a bit awkward to get back up and running.

Migrations are intended to deal as cleanly as possible with the happy path of upgrading databases, but there are a few caveats there especially with WebSQL. One key thing to be aware of is that SQLite (which WebSQL is run on top of) does not allow the deletion or alteration of columns.

At some point I'll implement the approach here (http://stackoverflow.com/questions/805363/how-do-i-rename-a-column-in-a-sqlite-database-table#805508) to perform those migrations, but just be aware they aren't in there right now.

Thanks for using the library, love to any hear any feedback so I can keep building on this getting to v1.0.

[Brett Coffin]

g'day mate, great job on the lib btw... I am still experimenting with it, one thing to mention:

ForeignKeySQLMapping.prototype.makeSQLField = function () {
        return this.name + " TEXT" + this.getConstraints();
    };

My service sends the ids as numbers and when sqlite does the conversion it adds a '.0' at the end of the id killing the relation... Which way do you recommend fixing this bug ?

[James Rakich]

Your number is getting coerced to a string prior to database insertion. Primary keys should always be strings in JohoDB, possibly misguided but the rationale is that sequential keys are impossible to guarantee due to the asynchronous nature of the calls. As such I'd prefer to recommend a string UUID or some other hash that won't collide, rather than attempt any sort of implementation that supports numbers directly.

If your use case is just using the WebSQL as a data cache, not necessarily allowing offline mutation, record creation, etc, then all I'd do is put a function that converts these key ids to strings after they've come through as JSON.

Generally with JohoDb I've always got an intermediate function that turns the server JSON into something the client can work with, I would argue that its rare that a client database needs to have the same structure as the server database, and you should endeavour to reduce complexity where you can on the client side, for example using JSON fields rather than building additional tables where it makes sense.

[James Rakich]

That said, I think this is a case for being more strict on validation, so I'll open an issue for that.