- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 2 Jul 2018 21:09:14 +0200
- To: "'Lorenzo Moriondo'" <tunedconsulting@gmail.com>, "'Hydra'" <public-hydra@w3.org>
- Cc: "'Akshay dahiya'" <xadahiya@gmail.com>, "'chris andrew'" <chrisandrew119@gmail.com>, "'Vaibhav Chellani'" <vaibhavchellani223@gmail.com>, "'sandeep chauhan'" <sandeepsajan0@gmail.com>
On Saturday, June 30, 2018 11:50 AM, Lorenzo Moriondo wrote: > Client and server may need to uniquely identify an instance to keep track of its > updates and possibly updated relations, but since now the only way to address an > instance on the server is to use its primary key as generated by the SQL database > underneath; this may obviously lead to confusion if a pk is dropped and later > readded assigned to a different instance. Also for synchronisation purposes between > relations stored in the server and in the client, this may be relevant. > We are discussing the problem here: https://github.com/HTTP-APIs/hydrus/issues/215 Typically you never re-assign a primary key for pretty much the same reason. Any specific reason why you can't simply ensure that it isn't reassigned? The most trivial solution I can think of in case you can't simply store the last ID you assigned is to pair each ID with a timestamp to make it unique. > What do you think about? This may be defined at spec-level instead of left to single implementations? The semantics of an identifier shouldn't change.. otherwise pretty much all bets are off. Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Monday, 2 July 2018 19:09:37 UTC