In Tracks' case, updated_at is not a rails internal field used to keep track of database content because it's specifically added as part of several migrations in the Tracks codebase.
This sounds like it could be a bug in our API. Steve, could you file an issue for this in our bug tracker on Assembla (https://www.assembla.com/spaces/tracks-tickets/tickets). I can't specify when this might get looked at or fixed, but we've had a couple of people working on the API recently and they might be able to pick this up and fix it. In the meantime, the addition of a 'dirty' flag in your code is probably the best way to work around the issue. Thanks -- Matt On Dec 4, 2011 10:38 AM, "Christian Frank" <[email protected]> wrote: > > Steve, > > updated_at is a rails internal field used to keep track of the > database content I am not sure about the particulars, but the > intendend behavior is that every time a field is actually written to > the db updated_at is set to the current time. Rails includes some > optimizations that can sometimes avoid writing to the db, e.g. when it > knows that the record you're trying to save is identical to the one > that's in the db already, in which case updated_at does not get > changed. Net, I would not recommend fighting it and relying on being > able to write anything but the current datetime to updated_at. > > Here's a potential alternative: > Add a 'dirty' bit to your local clients' databases and keep a global > timestamp of when the last sync happened. > Set the dirty bit every time a todo / project / context is changed. > That way you know which ones to push to the server come sync. When > the server receives those records it will set 'updated_at' to the > current time in its database as intended. After the push reset the > 'dirty' bits. > > Next you'd have to pull updates from the server. You will probably > want those records where the updated_at time is newer than the > last_sync (using the global timestamp) and older than the beginning of > the current sync operation. That way you avoid re-getting the todos > you just updated but you'll get everything that changed since the last > sync, even if it came from other clients. > > I am not sure this approach is fully baked, for instance it completely > ignores dealing with conflicts when the same todo was updated on two > separate machines, in wich case the last to sync wins. > > On a separate note, is your desktop app available anywhere? A > frontend that can be used off-line would really improve the usability > of Tracks for me. > > Hope this is helpful, best > Christian > > > On Dec 4, 2011, at 5:37 AM, "Steve & Renae Georg" <[email protected]> wrote: > > > Hi All, > > > > I have written a small desktop app that I use for tracks. Currently just > > use dropbox to keep sqlite databse file sync'd across machines which is a > > bit of a fudge and I occasionally get conflicts due to using a netbook > > offline quite a bit. > > > > I was writing a script that would sync a local db to a tracks server using > > the api. It was syncing contexts and projects quite well using updated-at > > to detect changes but has come unstuck on todos because I don't seem to be > > able to write updated-at to a todo consistently, the server is overwriting > > it with the current time (although it occasionally does work, which is > > odd). As it has changed the field the two db's aren't sync'd and I detect > > the changes on the server. I can probably work around this by doing two > > syncs in a row but I would prefer to keep the original updated-at value. > > > > E.g. If I post this old todo to the api the updated-at field will be > > changed to todays date. When I do similar with a project it will keep the > > old value. > > > > <todo> > > <context-id>481</context-id> > > <project-id>713</project-id> > > <description>Add aero bling in windows(tm)</description> > > <created-at>2010-08-13 13:19:13</created-at> > > <completed-at>2010-08-13 13:19:17</completed-at> > > <state>completed</state> > > <updated-at>2010-08-13 13:19:17</updated-at> > > </todo> > > > > > > So question is: What is the intended behavior, should I be able to write to > > the updated-at field? If I should be able to, any ideas on why it is not > > working on todos? > > > > > > Cheers, > > > > Steve > > _______________________________________________ > > Tracks-discuss mailing list > > [email protected] > > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
