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
