0

Lets imagine the following scenario:


I have a system that is on web, you can add data update it etc. Then you have a mobile phone which obtains the data from server.


How will I keep track of the latest versions? In one word how will the device know when to sync?

The app needs to be offline, and when it connects to the internet I thought of sending versions of each tables, then if the version on the phone is lower than on the server, then the server would return just the new data.

Also I thought of sending a version of every data to check if something is updated.

Is there a better solution on this than mine? Since I don't want to send each datas version, there could be 400 versions, and each one needs to be compared. I think that over time it would cause issues as the user base grows.

  • There may be, but we need more details on the application to be able to answer this. The question is very vague – TheCatWhisperer Jun 20 '17 at 15:06
1

I have a system that is on web, you can add data update it etc. Then you have a mobile phone which obtains the data from server.

This is vague enough to cover every kind of communication what-so-ever.

In one word how will the device know when to sync?

There are two ways. Your device can ask to sync and then receive data. This is acting like a client. Your device can receive data as a pushed notification. In this second situation your device is acting like a server.

The essential difference is whether or not your device is in control of when this communication happens. If it's not then something else is.

Also I thought of sending a version of every data to check if something is updated.

This is called polling. It's not the best situation to find yourself in. It happens when you don't know when something will happen yet you're stuck acting as a client that is responsible for deciding when communication will happen. Since you don't know, you just keep repeatedly asking. Doing it has serious performance and bandwidth consequences. It's as annoying as the 5 year old's who chant "Are we there yet?"

It's far better to find a way to let the something-that-knows-when decide to connect to you and tell you what happened. These ways have many names: events, push notifications (notify), updates, posts, calls, and messages.

If you need to teach the something-that-knows-when who it needs to tell it's called registering as an observer. The design pattern that teaches all this is the observer pattern. Most of the examples you'll find are about objects communicating across threads. Regardless of the architecture involved, following this pattern will save you from polling.

Since I don't want to send each datas version, there could be 400 versions, and each one needs to be compared. I think that over time it would cause issues as the user base grows.

All you need to be told about is the change. You don't need the entire history of changes.

Digging this change out of a database really is the hard way to do it. Unless you're explicitly trying to do database replication (a fairly hard problem) it's far better to have whatever told the database about the change to also tell you about the change.

Databases make fairly poor message queues. Trying to make them do this sort of thing is essentially trying to build a message queue after the fact. That's like trying to unbreak an egg. It's better to treat the database as just another observer of the something-that-knows-when.

Of course I'm not saying you can't do it the other way. Just trying to point you to what could make this a far easier problem.

2

Let's say we have a single overall version number maintained by the server (in a table), and it increments each transaction that is committed to the database.

And the database is setup to also maintain a version number column in each table, so that each row has a version number. Whenever a row is modified or added, the single overall version number for that row must be updated to the next value for that single overall version number. (An updated row will have its version column updated all the way to the latest version value in question regardless of its prior value.)

Further, the server returns to the client the latest of that single overall version number on each query.

When syncing client's version information is used in query, and so to its queries where clauses, for each table, a conjunction is added that restricts results to rows whose change version is >= that version number.

This will make the database do the work of identifying things that have changed since the (some given) last version (number).

Your mileage will vary, as sometimes on joins you will want the version restriction and other times not (e.g. a query to categories of items, you may want items that changed, but always get all their categories regardless of changes in the categories).


The above provides an algorithm to determine exactly what has changed since last sync. Now as to the question of when to sync. As @CandidedOrange says, the right time to sync is when a change has occurred, as now we're pushing change rather than needlessly pulling/polling.

So, someone, somewhere (either the client or the server) needs to understand the last version that each client did actually see.

As @CandidedOrange is alluding to, the work can be factored into two components:

(1) the server notices change, and pushes notifications. If the server knows the latest version number for each client, it can push the specific changes to each client for clients that will see changes (computing them as per the above algorithm). But if the server doesn't the latest version seen by each client, then it just pings all the client to try an update.

(2) When clients are pinged, either they get the change set (if server maintains latest client version), and in the other approach the client turns around and pulls changes from the server with the client's latest version number, updating as needed.

  • So in my case i would crate a audit trail to keep track of the data changes.And in it i would add the table version,so when the admin performs a change it will increment it.And when the client send me its version number i would determine all changes by the main table number? – DaAmidza Jun 20 '17 at 15:19
  • right, the level of automation you apply to maintaining the version number's latest value, as well as to updating the captured version number value on rows is up to you. Though it would obviously be best if this were handled automatically, I'd probably consider putting a service front end that would take care of updates and ensure queries use the client supplied version properly. – Erik Eidt Jun 20 '17 at 16:01
  • Also note that this single overall version number could be a database version number covering multiple tables. – Erik Eidt Jun 20 '17 at 16:02
  • Yes sure i got that part ,tanks man :D Tho i was thinking about this approach i didn't see it working.But after thinking more i think its the best solution. – DaAmidza Jun 20 '17 at 16:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.