EsupDematEC

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

  1. Il est conseillé d'éviter de faire des mises à jour de versions majeures en pleine campagne.
  2. Une nouvelle campagne requiert de repartir d'une base de données quasi vierge (archivez les candidatures avec la commande adéquate avant, cf question ci-dessus) - puis pour la mise en place de la nouvelle campagne : 
    1. vous pouvez simplement repartir de zéro au niveau de la base (base complètement vierge, configurations à ressaisir)
    2. si vous souhaitez récupérer les configurations (correspond à une tableappli_config et depuis la 1.3.0 également à  appli_config_file_type) et les comptes admin et (super-)manager (correspond à la table des utilisateurs c_user), vous pouvez éventuellement supprimer les données via la commande deletedata, mettre à jour votre code EsupDematEC (on vous conseille de gérer cela via git) puis migrer la base via dbupgrade.
  3. Si vous avez pris "trop"  de "retard" entre les différentes versions, repartez d'une base et d'une installation vierge ; reprenez 'manuellement' (ou par script sql) les quelques configurations que vous souhaitez et que vous pouvez reprendre. Les mises à jours de versions majeures éloignées n'ont pas été validées ni testées (de la 1.0.3 à la 1.3.0 par exemple).

EsupDematEC peut fonctionner en load-balancing ?

Actuellement EsupDematEC est prévue pour fonctionner sur une seule instance d'un serveur web Java type Tomcat. Son fonctionnement en load-balancing est donc actuellement déconseillé.

Détails techniques supplémentaires ici : 

Techniquement, le fait que tout soit stocké en base de données pourrait faciliter le support du load-balancing (pas d'accès concurrent à un file system à gérer notamment.
Cependant pour faciliter le développement et optimiser les performances, nous avons choisi de mettre en cache (cache simple en mémoire) les paramétrages de l'application issus des tables  appli_config et galaxie_mapping - ce cache est mis à jour lors de la modification par l'IHM des paramétrages - dans un fonctionnement en load-balancing, il ne serait alors mis à jour que sur une seule instance.