In a recent project, we decided to embark on a one way SYNC for a solution that is offline. And been having to deal with many of the shortcomings of what we have available currently.
I know that Chris suggested an idea around SYNC and I love it. SYNC in the background etc. But SYNC gets to be a complicated topic very quickly. So I wanted to offer a different twist to it.
Currently, if you go to a layout where you have fields that belong to the hosted copy of the file and run your scripts to SYNC data to the hosted copy, what you'll find is that you can't close that hosted file once you have opened it. No matter how you try, Unless you close the file that opened it. Doesn't make for a great user experience. So the first thing we really need is a way to OPEN and CLOSE a connection to a file that we'll be moving data into or out of.
So first a reliable way to say OPEN and CLOSE connection - and maybe for backward compatibility, it could be called Open Connection instead of Open File. Or as Chris mentioned a change in file format and CLOSE really closes the file. But my feeling is that CLOSE does some special things under the hood that it might break many things. Not sure.
Anyway, once we have OPEN CONNECTION and CLOSE CONNECTION.
Then a new step called SYNC [from] - [to] what Table occurrence to what table occurrence.
This SYNC would only be one way. No conflict resolution, just take all my data and mirror it on the server in this FILE | TABLE. It could use some intelligent ways of figuring out that any data has changed by maybe maintaining a hash of some kind for that table. If the hash is different then something in the table changed. Maybe a record was modified, maybe a record was deleted. But the main point here is that there is NO conflict resolution. I guess one might even call this replication in a sense.
As a scripted process that we, as developers could control then it would be great if we could also see a progress when this is syncing.
If and when we get transactions within scripting then one could encompass the SYNC Basetables within the transaction
Bonus points if this could run in the background in some way. Maybe the table mapping is not added to the graph by a dedicated SYNC area. And they are not table occurrences but rather they are basetables. Each table mapping is an arrow that points in one direction or the other. And maybe one could specify how to sync | By Script | On Data Change | On Interval.
Then this could be running in the background. As soon as there is some new data if it can try to open a connection SYNC and close the connection.
Anyway, there you have it a simple and elegant and hopefully easy way to implement a one way SYNC that offers lots of flexibility.
Wanted to also link to Chri's idea here: Built-in Background Sync