Le 19/02/2014 15:13, Sigrid Lehuta a écrit :
hello Salut,
en regardant le script gravité de Loic, nous avons découvert une erreur piégeuse dans le script qui nous a poussés à creuser notre compréhension de la manière dont la base de données est modifiée durant une simulation.
Voici un résumé de ce que l'on a compris, pourriez vous valider/corriger ? On a pas l'ambition de tout comprendre mais plutot d'éviter des erreurs à l'avenir avec un niveau de compréhension suffisant, merci de votre aide.
La base de données d'ISIS est un objet TopiaContext
Elle est attaché à un simulationContext dès qu'une simu est lancée.
* Au cours de la simu on a donc accès aux objets de la DB via le simulationContext et de deux manières différentes : - soit l'objet est un paramètre de la simulation (population, stratégie...) et on passe par les simulationParameter pour réccupérer le topiaId de l'objet et le trouver directement dans la DB Population tmp = (Population) db.findByTopiaId(pop.getTopiaId());
- soit l'objet n'est pas un paramètre de la simulation et il faut passer par le DAO (genre d'interface avec la DB qui crée des instances des objets de la database qu'on peut modifier etc) pour recupérer l'objet dans la database ZoneDAO dao = IsisFishDAOHelper.getZoneDAO(db);
C'est généralement transparent pour l'utilisateur car le SiMatrix contient des méthodes qui nous cache ces processus la plupart du temps en créant des raccourcis méthodes : getPopulations(TimeStep step) getZones(TimeStep step) getStrategies(TimeStep step) etc Les autres objets sont généralement accessibles à partir des pop, strategies ou métier (mis a dispo dans les règles). On a simplement besoin du DAO quand on crée une nouvelle zone (cantonnement) ou un nouveau métier.
Le topiaContext s'il est modifié par une règle est restauré à la fin de chaque pas de temps.
* En dehors d'une simulation, en pré-simu ou post-simu d'un plan d'analyse par exemple, on a bien sur pas accès au simulationContext, mais on créer et accède à la database de la prochaine simulation de cette manière TopiaContext tx = nextSimulation.getStorage().beginTransaction(); et on peut la modifier via les objets DAO. PopulationDAO popDAO = IsisFishDAOHelper.getPopulationDAO(tx);
C'est bien ça? Oui, c'est pas mal ;)
D'où des questions: - pourquoi passer step en argument des méthodes getPopulations(), getStrategies() etc ? En effet elles prennent step en argument MAIS NE L'UTILISENT PAS. C'est piégeux. C'est bien la base de données initiale qui est renvoyée et pas la base potentiellement modifiée à un pas de temps de la simu. C'est un argument absolument inutile qui ne sert qu'à la gestion du cache dans Isis.
Par exemple : si la méthode était "getZones()", la même valeur resterait dans le cache pendant toutes la simulation. Avec "getZones(TimeStep)", on est sûr que la valeur sera actualisée à chaque pas de temps (ce qui est utile si des zones sont créées par des règles).
- Pourquoi on a pas besoin du DAO quand on connait le topiaId ? est ce que la méthode findByTopiaId() fait appel au DAO sans que ca se voit?
Un topiaId identifie un seul et unique objet dans toutes la base de données. Donc, rien qu'avec le context, Isis sait retrouver le bon objet. Le cas serait différent pour un findByName(). Dans ce cas un faut faire l'appel sur un dao particulier pour recherche par "name" de zone, "name" de population... -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28