Extracting information from a webservice

Pierre-Yves pingou at pingoured.fr
Fri Jan 18 08:21:50 PST 2013

On Fri, Jan 18, 2013 at 09:21:30AM +0100, Aurélien PRALONG wrote:
>    By the way, when I registered, I got this error :
>                          sqlalchemy.exc.IntegrityError
>    IntegrityError: (IntegrityError) column diver_confirmation_key is not
>    unique u'UPDATE divers SET diver_confirmation_key=? WHERE divers.diver = ?
>    AND divers.diver_creation_date = ?' ('ok', u'XXXXXXX', '2013-01-17')

Yes, this is a known error, we need to fix the database, hopefully we'll manage
to do it today.

>    When you store a dive in DB, I suppose you have a row like this :
>    ID;Latitude;Longitude;date;hour;Name
>    The idea is to give ID (or another unique ID if you don't want to give SQL
>    ID) to clients. So they can associate it to the dive, and when another
>    sync is done, the matching is easy (just a string comparison).

Well, actually no, I set the primary key to be the combination of diver/dive
name, but I realize that the change I pushed yesterday (allow dives with no
name) breaks this constraint. In sqlite this is apparently no problem but in a
decent database system it will breaks. I will start using alembic to allow
database migration.

>    > Which make me think, would we want a possibility to retrieve the dive
>    associated
>    > to someone for a given date or time period?
>    Good idea. A common (and easy) start would be to handle the
>    "Last-Modified" HTTP header (return all dives starting from client given
>    date).

I was thinking of keeping it simple by just providing a new API entry.

>    Speaking of dates, I wonder if we should merge "date" and "time" to one
>    XML datetime (e.g. 2013-01-17T22:12:10+01:
>    00) ? It would allow to add timezone information.

We might indeed. At the moment the webservice assume you are sending time in
UTC. The question is, do we handle time change in the client or the server. I
guess both are possible and I don't have really any preferences on this.


More information about the subsurface mailing list