• Save
pmsipilotMCOCriteria
Upcoming SlideShare
Loading in...5
×
 

pmsipilotMCOCriteria

on

  • 941 views

Présentation du Criteria PMSIpilot utilisé avec propel

Présentation du Criteria PMSIpilot utilisé avec propel

Statistics

Views

Total Views
941
Views on SlideShare
723
Embed Views
218

Actions

Likes
1
Downloads
0
Comments
0

5 Embeds 218

http://www.pmsipilot.org 207
https://twitter.com 5
https://www.linkedin.com 3
http://www.slideshare.net 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

pmsipilotMCOCriteria pmsipilotMCOCriteria Presentation Transcript

  • Réunion technique PMSIpilot 06 Juin 2009
    • Du Context au Criteria
    • L'utilisation dans MCO
    • Le fonctionnement
    • Le filtrage dans MCO
    • Pourquoi forker Propel ?
    Agenda
    • Objectifs :
      • Permettre la réalisation du Requeteur
      • Filtrage multiple sur MCO (filtre premium)
      • Utilisation de tables virtuelles et partitionnées
      • Utiliser ces mécanismes de manière transparente pour le développeur
    Du Context au Criteria
    • 3 notions :
      • Context : Conteneur d'information
      • Criteria : Objet permettant de générer du code SQL
      • Criterion : Composant du Criteria, permet de générer des bouts de SQL
    Du Context au Criteria Context Criteria Périmètre Criterion
    • Appel du pmsipilotMCOCriteria toujours à partir du pmsipilotMCOContext
    • Cloner le Criteria lorsque l'on modifie l'objet
    • Utilisation d'une méthode getPerimetre du context pour passer des paramètres supplémentaires
    • $perimetre = $context->getPerimetre('rumag',array(RumPeer::TARIFRUM, RumPeer::GHS, RumPeer::DATEEFFETTARIF);
    • $criteria = clone $context->getPmsiCriteria($perimetre);
    L'utilisation dans MCO
  • L'utilisation dans MCO V4 V5
    • Choix de la table principale
    • Mappage de la table
    • Initialisation des tables partitionnées
    • Ajout du filtrage
    • Ajout des tables temporaires
    Le fonctionnement
    • Les méthodes de l'API
      • bindToAnotherTable($to, $from)
        • Lie une table à une table virtuelle (ex table rum vers une table virtuelle)
      • initMap($table)
        • Créé le mappage de la table et active les tables partitionnées
      • generatePartTable($table, $annee)
        • Génère les tables partitionnées pour l'année concernée
      • changerNomTable($champ)
        • Change le nom d'un champ (ex: rss.NroRSS) en un nom utilisant la table virtuelle ou partitionnée (ex : rss_08.NroRSS)
        • Utilise un template pour choisir dynamiquement le nom de la classe (:peer::NOMCHAMP ---> RumPeer.Nom_champ)
    Le fonctionnement
    • $perimetre = $context->getPerimetre('rumag',array(RumPeer::TARIFRUM, RumPeer::GHS, RumPeer::DATEEFFETTARIF); $criteria = $context->getPmsiCriteria($perimetre);
    1 2 3 : initMap (rum) 5 : filtrage 4 : création Criteria rum 6 : création table temporaire 7: traitements Table tmp 9 :Bind table rum vers table tmp Le fonctionnement Contrôleur Context Criteria Criteria filtrage Criteria Temporaire Génération Table tmp
    • En 2 temps
      • Génération de Criterion stockés dans le Criteria
      • Intégration des Criterion
    • 4 types de filtrage
      • Periode
      • Verclass
      • UM
      • Filtre premiums
    Le filtrage dans MCO
    • 3 cas d'intégration du filtrage dans le Criteria
      • Criteria sans table virtuelle
        • Avec jointure dans le filtrage
          • Utilisation d'une table temporaire de filtrage
        • Sans jointure dans le filtrage
          • Ajout des conditions dans la clause WHERE
      • Criteria avec table virtuelle
          • Ajout des conditions dans la clause WHERE du SELECT qui va servir à remplir la table virtuelle.
    Le filtrage dans MCO
    • 2 contraintes principales :
      • Faire des jointures complexes :
        • Ex : tableA LEFT JOIN table2 ON (tableA.ch1 > tableB.ch2 OR tableA.ch3 <= tableB.ch3)
      • Éviter de cumuler les jointures sur une même table et pour une colonne identique.
        • $crit->addJoin(RumPeer::NRORSS, RssPeer::NRORSS);
        • /*** un peu plus loin ***/
        • $crit->addJoin(RumPeer::NRORSS, RssPeer::NRORSS);
    • Obligation de faire ces modifications dans la classe mère Criteria
    Pourquoi forker Propel ?
    • Autres modifications du comportement de Propel
      • Surcharge de la méthode add();
        • Additionner les conditions au lieu d'écraser.
    • Surcharges des méthodes du Criteria
      • Remplacer les noms des tables par celles des tables partitionnées et virtuelles.
      • Utilisation de changerNomTable()
    Pourquoi forker Propel ?
    • Points faibles du Criteria/MCOCriteria/SQL
      • 2 jointures sur la même table avec des conditions différentes -> PropelException
      • Nom de la table temporaire basée sur la signature de l'objet MCOCriteria
      • Jointure sur la table temporaire de filtrage coûteuse lorsque la condition de filtrage est peu filtrante
    Pourquoi forker Propel ?
    • Empiler les tables temporaires
    • Récupérer un Criterion de filtrage
    Autres possibilités