Extracting information from a webservice

Aurélien PRALONG aurelien.pralong at gmail.com
Wed Jan 23 07:49:23 PST 2013


> From an algorithm point of view however, I am not sure it does. I think
> you are implying that dive number in the web-service will correspond to
> the dive number in the desktop application. Am I right?
Yes

Here is the workflow :
1) The client (companion or subsurface) creates a dive, with local ID 'X'
2) I upload it to the webservice
3) The webservice returns to me the ID 'Y'
4) The client add to my dive the server ID 'Y'. For now, if I receive an ID
'Y' from the server, I'll find it easily, without duplicates.

My major assumption is that there is no duplicate between server and client
: you can not have a dive on the server and one on the client, and
logically consider they are the same dive.

And no, I do not rely on the 'increment' part or any other predictible ID.
You could use a GUID (as in microsoft SQL server), it would be the same
algorithm.

I hope I'm more clear.

Aurélien


2013/1/23 Pierre-Yves Chibon <pingou at pingoured.fr>

> On Wed, 2013-01-23 at 16:01 +0100, Aurélien PRALONG wrote:
> Oops sorry, I made it too quick.
> >
> > I just thought the matching between server dives and subsurface dives
> was
> > too complicated. So I just suggered, on the server side, to add an
> auto
> > incremented primary key (=PK) in the dive database (=DB), and transmit
> it
> > to clients, so matching could be easy (string comparison).
> >
> > We discussed of this with Pierre, and it appeared the key for dives
> was a
> > combination of diver / dive name. Maybe this change would break DB
> > relationships or elsewhere ? If no, I think a row having it own key is
> > cleaner for databases.
> >
> I see two different issues here, the first is the database design and
> the second is the gps <-> dive matching algorithm.
> From a database design, using an incremental integer as primary key
> might make sense.
> From an algorithm point of view however, I am not sure it does. I think
> you are implying that dive number in the web-service will correspond to
> the dive number in the desktop application. Am I right?
> If that was the case, the matching would be indeed much easier. But I
> won't be the case as:
> a) My divelog starts at 9, since I have made 8 dives before having my
> dive-computer, so the first dive which I would have in the web-service
> will not be the first in my divelog.
> b) I might forget to bring my phone on the boat, or forget to turn it on
> on site, therefore skipping a number between the web-service and the
> client.
> c) There are more than one person using the web-service, meaning if
> dives #1 and #2 are yours, maybe #3 and #4 and #5 are actually from 3
> different persons.
>
> If you are not making this assumptions (dive # consistent across the
> web-service and the client), then I do not quite see how having a unique
> integer attached to each dive will help in the algorithm. Could you
> elaborate?
>
> Pierre
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130123/160bf35c/attachment.html>


More information about the subsurface mailing list