J'ai le même problème avec un projet sur lequel je travaille, la solution dans mon cas était de créer un champ nullable supplémentaire dans les tables locales nommé remote_id. Lors de la synchronisation des enregistrements de la base de données locale vers la base de données distante si remote_id est null, cela signifie que cette ligne n'a jamais été synchronisée et doit renvoyer un ID unique correspondant à l'ID de la ligne distante.
Local Table Remote Table
_id (used locally)
remote_id ------------- id
name ------------- name
Dans l'application client, je relie les tables par le champ _id, à distance j'utilise le champ id distant pour récupérer des données, faire des jointures, etc.
exemple localement:
Local Client Table Local ClientType Table Local ClientType
_id
remote_id
_id -------------------- client_id
remote_id client_type_id -------------- _id
remote_id
name name name
exemple à distance:
Remote Client Table Remote ClientType Table Remote ClientType
id -------------------- client_id
client_type_id -------------- id
name name name
Ce scénario, et sans logique dans le code, entraînerait des échecs d'intégrité des données, car la table client_type peut ne pas correspondre à l'id réel dans les tables locales ou distantes, donc chaque fois qu'un remote_id est généré, il renvoie un signal à l'application cliente demandant de mettre à jour le champ _id local, cela déclenche un déclencheur précédemment créé dans sqlite mettant à jour les tables affectées.
http://www.sqlite.org/lang_createtrigger.html
1- remote_id est généré sur le serveur
2- renvoie un signal au client
3- Le client met à jour son champ _id et déclenche un déclencheur qui met à jour les tables locales qui rejoignent le _id local
Bien sûr, j'utilise également un champ last_updated pour faciliter les synchronisations et éviter les synchronisations en double.