[ALOY-508] sql_new adapter doesn't save the id provided when creating a new object
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2013-02-07T13:53:05.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Alloy 1.1.0, 2013 Sprint 03 |
| Components | Runtime |
| Labels | qe-port, qe-sdk3.0.2 |
| Reporter | Jordi Vicedo |
| Assignee | Tony Lukasavage |
| Created | 2013-01-24T06:49:32.000+0000 |
| Updated | 2013-03-12T18:16:48.000+0000 |
Description
When you create a new object like:
m = Alloy.createModel(modelName);
m.attributes.customID = 1234;
m.save();
it doesn't save the id provided. I think that this provided should be saved, because if you provide this value is because you want this object to have this id (for example for synchronizing from another source).
Assuming this is the desided behaviour, the line that is wrong is (sql_new.js:98)
model.idAttribute === ALLOY_ID_DEFAULT ? model.id = util.guid() : model.id = null;
And should be replaced by:
model.idAttribute === ALLOY_ID_DEFAULT ? model.id = util.guid() : model.id = model.attributes[model.idAttribute];
Why wouldn't you just set m.idAttribute to "customId"?
In the model, is set to customid: {noformat} [...] "adapter": { [...] idAttribute: "customID" } [...] {noformat} After working with Alloy for various days, I've found that we don't need this: we can make any field a primary key, and then retrieve the object using a query ( collection.fetch{query: ... }); )
OK, I'm understanding what you mean in the original ticket description now. I'll take a look and see what I can do.
On a side note, use
m.set('customId',1234), notm.attributes.customID = 1234;. Setting m.attributes directly will circumvent any Backbone.js eventing that should take place.Resolved, tested, and will be available in Alloy 1.0.0. The easiest way to test this fix is to use the [models/sql_keywords test app](https://github.com/appcelerator/alloy/tree/master/test/apps/models/sql_keywords), but *BEFORE* running it, make sure to remove the *AUTOINCREMENT* keyword from both the model and migration files. In addition, add a *fighterId* field to each inserted row in the migration. The changes are summed up in this gist: https://gist.github.com/tonylukasavage/4731041 Make these changes in the test app, before running it, then run it and inspect the sqlite db file on the simulator/device to confirm that the ids from the migrations are used, not autoincrement ids.
Verified fixed on 1.0.0-cr and 1_0_X latest branch on iOS (iPAd 6.0, iPhone 5) and Android (Nexus 4 4.2, Nexus 7 4.1.2 and Nexus One 2.2.2)