Solution pour modifier un module existant ?
#11
CremeAbstractEntity est un relicat datant d'il y a bien longtemps, mais plus forcément d'actualité en tant que classe mère des entités et des relations, dans la mesure où pas mal d'attributs hérités ne sont jamais utilisés par les relations. Mais comme quelques questions restent encore en suspend à propos des relations, ce nettoyage n'a pas encore eu lieu.

Dans l'absolu faire un contribute_to_model() sur CremeEntity ne pose pas trop de problème, SAUF avec les classes abstraites qui dérivent de CremeEntity (ce qui arrive seulement dans 'tickets'), à cause du conflit avec les classes abstraites dont j'ai déjà parlé. Pour un client j'avais utilisé contribute_to_model() pour ajouter un UUID à toutes les entités, et effectivement bien que la nouvelle ligne correspondant à ce champ était bien en base, les instances de Tickets ne "voyaient" pas ce nouveau champ ; les autres types d'entités fonctionnaient bien il me semble (car au final dans mon cas j'ai été obligé de modifier directement CremeEntity, ne voulant pas faire une croix sur 'tickets'). Je n'ai absolument aucune idée de ce qu'est votre problème de populate car vous ne donnez aucune info là dessus.

Vous pouvez aussi tout simplement créer un model ayant une ForeignKey vers CremeEntity ; même si potentiellement cela peut vous obliger à faire des jointures dans vos requêtes, ou bien des requêtes imbriquées, ou juste des requêtes supplémentaires, cela ne devient éventuellement un problème qu'avec un grand nombres d'objets (et encore faut-il prouver que les problèmes viennent de là).

En fait c'est _déjà_ ce que font les Propriétés (au sens Creme, pas Python), qui sont des sortes de tags typés. C'est un des concepts fondateurs de Creme, et elles sont donc bien intégrées à l'application. Vous devriez sûrement regarder de ce côté là.
  Répondre


Messages dans ce sujet

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)