On Mon, Dec 5, 2011 at 6:25 AM, Matt Rogers <[email protected]> wrote: > On Mon, Dec 5, 2011 at 2:35 AM, Reinier Balt <[email protected]> wrote: > >> > >> 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. > >> > > > > Not true. > > The field was added by a migration to support the rails version that > > introduced auto-mgt of updated_at. Tracks roots are very old :-) > > > >> 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. > > > > I don't think this can be fixed easily, see explanation of Christian. > > > > Reinier > > > > Learn something new everyday. :) I assumed since it was part of a > migration that it was added manually. Forgot that you'd have to add > migrations for rails internal stuff too with Tracks being as old as it > is. > > Thanks! > -- > Matt >
Steve, one more question on your sync problem: I didn't see the sync script that you're developing in GitHub (maybe I missed it), but how do you know which record IDs to pass back and forth? If the local and the server tracks dbs were in sync before and you added a todo to each of them they would have the same ID but be different todos. How (if at all) does your script deal with this? Also, how do you deal with todos that are deleted either locally or on the server? All, based on the exchange with Steve this weekend I was thinking a bit more about how to get an off-line client to work for airplane rides, etc., but also for use across slow or expensive connections where working on-line is just too painful. Something along the lines of offline email where you replicate your new / changed email to the local machine, work with it and every once in a while replicate it back to your central mail file on the server. Note, I'm not advocating re-architecting Tracks into a client / server app, but I'd like to be able to create a client that uses Tracks as if it were the server. For the client, I like the idea of just using a locally installed copy of Tracks because it avoids reinventing the wheel, and can be kept current with minimal effort. It would be a little heavy, because of the DB, web server, RoR, but better that than having to maintain more code. The poor man's version of this idea would be to have a single database and do some sort of checkout / checkin every time you go on the road, or Steve's dropbox approach. It would work right now, but it's not very practical in the long run. Another option, and the one I'd like some feedback on, is to allow the local copy and the server copy of Tracks to synchronize. Since rails IDs are not unique across clients, it seems to me that we would need to start with assigning GUIDs for each context / todo / project (=CTP). During replication the client(s) need to check if a local CTP's GUID is dirty which means it needs to be replicated. The server needs to send all CTPs that had any changes since the last replication with that client. Further, the client(s) and the server would need to keep a list of GUIDs for deleted todos, in case of the server almost indefinitely, in case of each client until it has pushed the delete to the server. Dealing with dependent actions would be tricky and I would expect a bunch of nasty corner cases, but does this seem workable to you all? Also, what is the overall interest in an off-line / slow line client? Lastly, is there a better answer that would also work on tablet / phone platforms? Best Christian
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
