Migration 1.1 vers 1.2 RC3
Envoyé par: Fred ()
Date: mardi 18 octobre 2005 08:33:35


Bonjour à tous,

Nous avons migré un premier client en version 1.2 RC3 en direct depuis une 1.1.
Nous avons rencontré des soucis importants concernant les réservations en cours. En effet, le fait de passer le club en fuseau Europe/Paris ainsi que les membres,
notre planning s'est retrouvé décalé de 2 heures. Chaque réservation a pris deux heures de retard, avec par contre un affichage de la journée aéro parfait.

Nous sommes actuellement en cours de traitement des données par requête sur la base mysql.

Frédéric NAUDIN
VARIO Positif

Options: RépondreCiter
Re: Migration 1.1 vers 1.2 RC3
Envoyé par: claratte ()
Date: mardi 18 octobre 2005 22:46:00

Bonjour,

Je n'ai pas encore eu le temps de vérifier la "réalité" du bug (c'est à dire prendre une version 1.1 et la migrer sur une 1.2RC3).

Néanmoins, si bug il y a (c'est à dire si l'heure est effectivement "trop décalée" ou pas "assez décalée"winking smiley voici la commande SQL a utiliser (via phpMyAdmin par exemple) :

update booking set start_date=date_sub(start_date, interval 1 hour)

où il faut éventuellement remplacer date_sub par date_add et le 1 de "interval 1 hour" par la quantité qui-va-bien.

Christophe LARATTE
OpenFlyers manager

Options: RépondreCiter
Re: Migration 1.1 vers 1.2 RC3
Envoyé par: Fred ()
Date: mardi 25 octobre 2005 09:10:42


Christophe,

Nous avons continuer nos migrations, le dernier heliclub sur un serveur chez un autre hébergeur qu'Amen nous a affiché le message de migration des heures UTC....
Ce qui veut dire que la procédure d'installation a été complête, alors qu'elle ne l'était pas sur les serveurs AMEN....

Sur l'héliclub pas de soucis, les heures sont correctes sans avoir à faire de retouche...

Cordialement
Frédéric NAUDIN

Options: RépondreCiter
Re: Migration 1.1 vers 1.2 RC3
Envoyé par: claratte ()
Date: mardi 25 octobre 2005 17:36:50

Bonjour,

Merci pour les infos.

Mais je ne comprend pas tout ;-)

Donc je vais expliquer ce qui doit se passer, comme cela peut-être pourrez-vous me dire comment cela c'est passé par rapport à commencer cela "devrait se passer" ?

Donc tout d'abord une petit retour en arrière pour expliquer ce qui a justifié notre passage à l'UTC dans la base de données :

Avant la 1.2, les dates (par date il faut entendre date+heure=datetime) étaient sauvées dans la base de données sans se soucier de savoir qu'elle était le fuseau utilisé. Donc en pratique, les dates dans la base correspondaient aux dates affichées par OpenFlyers, et les gens les utilisaient telles qu'elles. Implicitement, les dates correspondaient donc au fuseau du club (en France : TU+1 l'hiver et TU+2 l'été).

La nécessité de changer est parti d'un simple bug : lors des jours de changement d'heure nous avions un décalage entre le clic sur une rectangle d'heure et l'heure réellement affichée dans le formulaire de résa. Pourquoi ? je ne sais plus. Mais après réflexion, il est apparu que la source du problème venait du fait que les dates dans la base étaient implicitement des heures locales et que cela posait bien d'autres problèmes (impossibilité de savoir à priori en récupérant juste une base qu'elle était le fuseau donc les vrais heures de résa, impossibilité de faire des soustractions d'heures pour la future facturation, etc.). La solution était donc de passer à l'UTC pour la base de données. Cela offrait également un gros avantage : permettre à l'utilisateur de choisir son fuseau horaire.

Mais, pour passer d'une version 1.1 à une version 1.2, il faut donc modifier dans la table des résas (booking) toutes les dates pour qu'elle passent en UTC.

Pour ce faire, il faut connaitre le fuseau qui était utilisé implicitement sur l'ancienne version. Donc lors de la migration, OF demande le fuseau à utiliser. Normalement le fuseau proposé est le premier fuseau par ordre alphabétique qui correspond à ce que "devine" OF (je crois qu'il prend le fuseau du serveur en premier mais de mémoire je n'en suis pas sûr).

L'administrateur qui effectue la migration doit absolument vérifier le fuseau proposer et mettre le bon fuseau (en France : "Europe/Paris"winking smiley.

Ensuite, la migration se fait en retranchant la valeur du fuseau aux réservations en base de données. Cela tient compte bien sûr des heures d'hiver ou d'été (DST).

Exemple : une résa en France qui commencait l'été à 11h00, doit commencer après migration à 9h00 (dans la base de données).

Par contre, l'affichage doit être inchangé et tous les utilisateurs sont mis par défaut avec le fuseau horaire choisi par l'administrateur.

Voila !

Christophe LARATTE
OpenFlyers manager

Options: RépondreCiter
Re: Migration 1.1 vers 1.2 RC3
Envoyé par: claratte ()
Date: dimanche 30 octobre 2005 08:23:56

Bonjour,

Je viens d'effectuer un test sur une migration 1.1.1 -> 1.2RC3 et je n'ai rencontré aucun problème : les heures sont bien converties en UTC en tenant compte du fuseau horaire choisi au moment de la migration.

Christophe LARATTE
OpenFlyers manager

Options: RépondreCiter


Seuls les utilisateurs enregistrés peuvent poster des messages dans ce forum.
This forum powered by Phorum.