Titanium JIRA Archive
Alloy (ALOY)

[ALOY-542] idAttribute set to a model attribute that is of type text not persisting

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2013-03-15T22:05:15.000+0000
Affected Version/sAlloy 1.0.0
Fix Version/sAlloy 1.1.0, 2013 Sprint 06
ComponentsTitanium SDK
Labelsalloy, ios, model, sqlite
ReporterDavid Welch
AssigneeTony Lukasavage
Created2013-03-05T21:00:50.000+0000
Updated2013-03-26T01:07:53.000+0000

Description

The example of idAttribute in the alloy test examples (sql_keywords) works, but when setting idAttribute to a model attribute that is of type text it won't persist the data. Example app attached.

Attachments

FileDateSize
app.zip2013-03-05T21:00:50.000+00005766452

Comments

  1. Tony Lukasavage 2013-03-05

    Did you try this on a fresh project, or did you change the idAttribute after the SQLite database had already been built?
  2. David Welch 2013-03-05

    I tried this on a fresh project. After it didn't work I deleted the app and tried it without idAttribute where it worked.
  3. David Welch 2013-03-05

    It should be noted that it only works when artist_id is "integer PRIMARY KEY AUTOINCREMENT". If it's "integer PRIMARY KEY" or "text" the data won't persist. I delete the database each time to start fresh.
  4. David Welch 2013-03-05

    Clearly, when I set artist_id to "integer PRIMARY KEY AUTOINCREMENT" or "integer PRIMARY KEY" I change my code in index.js to set it to an integer instead of string.
  5. Tony Lukasavage 2013-03-05

    That's weird since the default behavior in the absence of the idAttribute is for alloy to create one itself, a GUID that is a TEXT field named "alloy_id". I'll have to dig into your sample to see why it's not working in your case.
  6. David Welch 2013-03-05

    I thought so as well since alloy_id is text. Either way I wasn't able to persist the data.
  7. Kaos Arts 2013-03-11

    Ran into this bug too. // idAttribute = "email" // This silently fails to save var userM = Alloy.createModel('userModel', {email: userEmail, name: "Test"}); userM.save(); // This works var userM = Alloy.createModel('userModel', {email: userEmail, name: "Test"}); userM.id = null; userM.save(); Looks like the root cause of this bug is that when idAttribute value is set the model.id is also assigned immediately, before its saved. Too soon. That causes backbone's isNew() to return false at save, and attempt an update instead of a create. Which then silently fails obviously (it'll even call the success function if you set one!) A hack-around is to set model.id = null after createModel() but before save().
  8. Tony Lukasavage 2013-03-13

    I found the same Kimberlee, apologies for not logging it here earlier to save the time of others investigating. I'm working on this one now.
  9. Tony Lukasavage 2013-03-15

    This turned out to be a lot more complicated than expected initially. Mainly because the resolution to this issue involved changing the way the sql adapter inserts and updates, which is now based on DB constraints. This in turn changed the properties of the default alloy_id field used for automatically assigning unique ids to models, which had implications on adding alloy_id to existing databases, particularly preloaded ones. Details of all this are covered in this commit (props to Aaron Saunders for the initial code for these changes): https://github.com/appcelerator/alloy/commit/d511ebd64b5b1e8f840d1be80b90f0639d251e87 In addition, the core issue of this ticket can be seen addressed in the following test app: https://github.com/appcelerator/alloy/tree/master/test/apps/models/sql_idAttribute

JSON Source