Extend derivation rules to create new instances of table or entity #316
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marcboulle
force-pushed
the
199-extend-derivation-rules-to-create-new-instances-of-table-or-entity
branch
5 times, most recently
from
7dbd2d8
to
cce3753
Compare
marcboulle
force-pushed
the
199-extend-derivation-rules-to-create-new-instances-of-table-or-entity
branch
8 times, most recently
from
fcd1ecf
to
167d697
Compare
marcboulle
force-pushed
the
199-extend-derivation-rules-to-create-new-instances-of-table-or-entity
branch
4 times, most recently
from
fcf8cee
to
2101699
Compare
marcboulle
force-pushed
the
199-extend-derivation-rules-to-create-new-instances-of-table-or-entity
branch
2 times, most recently
from
aab9f37
to
1d23f2b
Compare
Pour une instruction exploitee uniquement en debug, on utilise la macro debug en laissant le ';' a la fin Exemples: - "debug(int nValue);" - debug(nValue = 0); Nettoyage des anciens patterns qui etaient mal geres par le pretty printer. A eviter: - "debug(int nValue;);" - "debug(int nValue;)"
KWAttribute::Check - transformation des warnings en erreurs - ajout d'un controle specifiques au type TextList, qui doit etre associe a une regle de derivation Test dans LearningTest\TestKhiops\Bugs\DicoTypeWithMissingRule Modification des test unitaires de KWClass and KWClassDomain pour ne plus creer de variable de type TextList En effet, ce type de variable ne peut etre natif (une regle de derivation est obligatoire), et cela provoque une erreur de compilation des dictionnaires
Contexte: - la methode KWDerivationRule::Compile est optimisee en ne se declenchant pas si la regle est deja optimises (IsCompiled) - cependant, quand la methode est reimplementee, cette optimisation n'est pas effectuee lors des reimplementation. - cela declenche de nombreuse re-compilation des regles associee a des attributs utilises en operandes de plusieurs regles de derivation Correction, uniquement dans les methodes controlant le declenhement de la compilation: - KWAttribute::Compile - KWAttributeBlock::Compile - KWDerivationRuleOperand::Compile Resultats observes: environ 40% de compilation de regles en moins Tests complets sur LearningTest (full)
Tests preliminaires en utilisant les regles existantes avec reimplementation de
la methode GetReference a false pour indiquer que la Table en sortie est cree.
Creation d'un prototype de regle creant une vue en sortie: "ProtoBuildTableView"
- ajout de Learning/KWDRRuleLibrary/KWDRTableCreation.h, .cpp
- classe KWDRProtoBuildTableView pour prototyper le cas standard d'une vue
- reimplementation de la methode GetReference, en retournant false
- test en renvoyant en sortie la meme classe qu'en entree
- test additionnels:
- creation d'objets en sortie d'une classe differente de celle en entrée
- propagation des calculs sur les objets crees
- teste dans LearningTest\TestKhiops\z_TableCreationRules\TableCreationRules
- cela marche correctement, y compris pour la gestion de la memoire
Ce prototype indique que le framework existant des regles de derivation est un bon point de depart.
Prise en compte de vue comportant des Entity ou des Table native
Dans ce cas, la vue recopie les attribut correspondant de l'objet source de la vue, mais ceux ci-ne doivent pas
etre detruits au moment de la destruction de l'objet de type vue
KWObject:
- Set|GetViewTypeUse
// Indicateur de type vue pour un object, selon le type de creation d'un objet (cf. lCreationIndex)
// - utilisation standard:
// - les attributs natifs de type Entity ou Table sont crees a partir des lectures dans une database
// - il sont detruits avec l'objet
// - utilisation de type vue:
// - les attributs natifs de type Entity ou Table sont recopies a partir d'objets sources au moment
// de la creation de l'objet via une regle de derivation de creation de Table
// - il ne sont pas detruits avec l'objet, car deja detruits avec l'objet source
- lCreationIndex: pour des raison d'optimisation memoire, ce longint stocke plisuerus info
- index de creation
- indicateur de type vue (cf. GetViewTypeUse)
- taille du vectuer d'attribut (cf. GetSmallSize)
- la destruction/mutation est necessaire
- si attribute de type nRelation natif, et on est on pas dans une vue
- car tout attribut natif cree a partir d'un fichier de donnees doit etre detruit
- mais un attribut natif d'une vue est juste une reference a un attribut source de la vue, et il ne doit pas etre detruit
- si attribut calcule mais non reference: objet cree
- implementation: prise en compte systematique de GetViewTypeUse pour piloter la destruction ou mutation des Entity et Relation
- methodes concernees;
- DeleteAttributes
- CleanTemporayDataItemsToComputeAndClean
- CleanAllNonNativeAttributes
- CleanNativeRelationAttributes
- Mutate
Modification de la gestion attributs de type Relation correspond a un objet natif ou cree (non reference)
- on passe d'un test sur les KWAttributs de type "GetDerivationRule() == NULL" a "not GetReference()"
- methodes impactees directement
- KWClass::IndexClass
- KWMTDatabase::ComputeUnusedNativeAttributesToKeepForRule
- KWObject::Mutate: modifications majeures
- methodes impactees pour les assertions uniquement
- KWAttribute::GetInternalLoadIndex
- KWObject::DeleteAttributes
Amelioration des commentaires sur la gestion des attributs de type Relation crees par une regle
- KWClass: GetUnloadedNativeRelationAttributeNumber renomme en GetUnloadedOwnedRelationAttributeNumber
Amelioration de la Trace
- KWClass::IndexClass: ajout de trace (en utilisant la nouvelle methode interne WriteAttributes)
- KWDatabase::BuildPhysicalClass: legere modification
- KWMTDatabase::ComputeUnusedNativeAttributesToKeep: ajout de trace conditionne par bTrace
Corrections au passage dans KWLearningProblemView
- ComputeStats, BuildConstructedDictionary, CheckData:
- test sur le dictionnaire deplace en premier
- supression du test sur la valeur de selection de la base d'apprentissage, redondant avec la verification de la base
- CheckData:
- ajout d'un test sur la validité des spécification de la base, notament en multi-table
Creation de plusieurs jeux de test par complexite croissante: TestKhiops\z_TableCreationRules
Mise en place de classes de service ancetre pour les regle de creation:
- KWDRRelationCreationRule
- GetReference: renvoie true
- Compile: memorisation de la classe cible et des index source cet cible de attributs a copier
- CheckOperandsCompleteness: debut d'implementation des constraintes pour les aliemntations de type vue
- IsFirstOperandViewType: methode virtuelle pour indiquer que le premier operande est la source de la vue
- NewTargetObject: creation d'un objet de type vue (cf. KWObject::GetViewTypeUse)
- CopyObjectCommonNativeAttributes: recopie optimisee des attributs de vue
- KWDRTableCreationRule
- KWDREntityCreationRule
KWDerivationRuleOperand::CheckCompleteness
- ajout d'une contrainte pour interdire l'utilisation d'une regle de creation de table en operande
KWDRRelationCreationRule::BuildAllUsedAttributes
- premiere implementation qui marche
- teste dans LearningTest\TestKhiops\z_TableCreationRules\TableViewErrors avec de nombreux effets de bord
- ne prend pas en compte une optimisation poussee
- complexe a mettre en place
- il faut evaluer quels attributs sources de la vue snt effectivement utilises en fonction des
attributs cible de la vue utilises par d'autres regles
- comme une vue peut etre calcule depuis plusizeurs dictionanires sources differents, un meme attrbut cible
de vue peut avoir une source de natrure distinctes selon le dictionnaire d'origine
- acctuellement, on intégre systematiquement tous els attributs source de la regle BuidTableView
- mais on pourrait evaluer de faon fine quels sont les seuls attributs sources vraiement necessaires
Au passage: correction de deux warning dans KDMultiTableFeatureConstruction.cpp
Prise en compte des regle de creation de table avec alimentation de type calcul
Pour un dictionnaire en sortie, on distingue deux type d'alimentation des variables:
- alimentation de type vue: valeur des variable recopiee depuis les variable de meme nom de la table en entree
- alimentaion de type calcul: la regle designe les variables en sortie a mettre a jour
- on utilise ':' pour separer les operande en entree des operande en sortie de la regle
- il peut y avoir plusieurs operandes en sortie, separes par des ','
- chaque operande en sortie designe explicitement un nom de variable native a alimenter dans le dictionnaire en sortie
CMakeLists.txt: amelioration d'un commentaire
CMakePresets.json: parametrage temporaire de BUILD_LEX_YACC": "ON" pour mettre au point le parser
Modification du parser de dictionnaire
- KWCLex.lex:
- prise en compte du caractère séparateur ':'
- KWYac.yac:
- renommage de la regle keyFieldList en fieldList
- la regle derivationRuleBody admet desormais une nouvelle variante de syntaxe avec specification des operandes en sortie
- parsing d'une liste d'operandes pour les operandes en sortie
- interet
- permet d'avoir des erreurs de syntaxes plus precises
- au dela de la specification des nom de variables en sortie, permet d'envisager
n'importe quel type d'operande en sortie (constante, regle de derivation)
- impact
- nouvelle regle dediee au parsing d'une liste d'operandes de taille non nulle
- nouveau type de token oaOperands
- fonctions dediees pour factoriser la gestion des operandes des regles parsees
- ImportParserRuleOperands
- ImportParserRuleOutputOperands
- ImportParserOperand
Deplacement de KWRelationRule dans KWData
- classes generiques de creation de Table ou d'entite
KWDRRelationCreationRule: classe ancetre
- specialisation de KWDerivationRule, comportant toute la gestion de la creation de table
- methodes dediee a la gestion des operandes en sortie
- Get|SetOutputOperandNumber
- Get|SetVariableOutputOperandNumber
- GetOutputOperandAt
- AddOutputOperand
- DeleteAllOutputOperands, RemoveAllOutputOperands
- DeleteAllVariableOutputOperands
- passage en virtuel des ùethodes suivantes de KWDerivationRule:
- RenameClass
- BuildAllUsedOperands
- ContainsCycle
- ComputeHashValue
- WriteUsedRuleOperands (nouvelle methode)
- redefinition de toutes les methodes a specialiser
- RenameClass
- CheckRuleDefinition, CheckOperandsDefinition
- CheckRuleFamily, CheckOperandsFamily
- CheckOperandsCompleteness
- ContainsCycle
- Compile
- BuildAllUsedOperands, BuildAllUsedAttributes
- CopyFrom
- FullCompare, GetUsedMemory, ComputeHashValue
- Write, WriteUsedRuleOperands
- InternalCompleteTypeInfo
- premiere implementation uniquement des methodes de base (principalement CopyFrom et Write)
pour tester le parser
KWDRTableCreationRule: classe dediee aux tables
KWCYac.yac: specialisation du parser pour gerer les operandes en sortie
- on garde l'essentiel du parser initial
- utilisation de la classe KWDRRelationCreationRule pour specialiser KWDerivationRule, uniquement en deux endroit
- pour stocker les operandes en sortie quand le parser en reconnait
- pour les exploiter au moment ou on verifie la regle
KWDRBuidlRelation, dans KWDRRuleLibrary
- KWDRProtoBuildTableView: prototype de regle avec alimentation de type vue
- KWDRProtoBuildTableAdvancedView: prototype de regle avec alimentation de type calcul
Nettoyage des methodes inutilises, dont la maintenance pour les regles de creation est lourde et sans interet: - KWClassDomain - RenameAttribute - KWClass - RenameAttribute - KWDerivationRule - RenameAttribute - DeleteLastOperand - ComputeAttributeName - KWDerivationRuleOperand - RenameAttribute - ComputeOperandName
…put variables Implementation de la specialisation des methodes dediees aux variables en sortie - KWDRRelationCreationRule - RenameClass - CheckRuleDefinition - CheckOperandsDefinition - CheckRuleFamily - CheckOperandsFamily - CheckOperandsCompleteness - Compile: compilation complete pour les aliemtation de type vue et calcul - BuildAllUsedAttributes - FullCompare - GetUsedMemory - ComputeHashValue - InternalCompleteTypeInfo - IsFirstOperandViewType : renomme en IsViewModeActivated KWDerivationRule - on precise que la gestion des regles de crreation de relation est sous-traitee a la classe dediee KWRelationCreationRule - ajout des methodes de gestion des operandes en sortie en virtuel - minimaliste: uniquement trois methodes de consultation des specifications - GetOutputOperandNumber, GetVariableOutputOperandNumber, GetOutputOperandAt - permet une implementation generique plus simple dans le parser KWCYac.yac et dans KWRelationCreationRule Au passage, refactoring basique: - KWDerivationRule::CheckOperandsDefinition - KWDerivationRuleOperand::CheckDefinition - KWDerivationRule::RegisterDerivationRule: verification par un require que la regle est correctement definie KWDRProtoBuildTableAdvancedView - nettoyage - alimentation de type vue et calcul testes sur un cas elementaire avec une seule variable en sortie
Passage a l'implementation des regles "officielles" - regles - BuildTableView - BuildTableAdvancedView - BuildEntityView - BuildEntityAdvancedView - BuildEntity - Supression des règle temporaires prefixees par "Proto" KWDRRelationCreationRule - SetVariableOutputOperandNumber: precision de la semantique en cas de nombre variables d'operandes - IsValidOutputOperandType: test de validite du type d'un operande en sortie - CopyObjectCommonNativeAttributes: renomme en FillViewModeTargetAttributes - FillComputeModeTargetAttributes: - alimentation des attribut cible pour les operande en sortie de regle - actuellement, implementation specifique aux besoins de BuildTableAdvancedView - amelioration des messages d'erreur - specialisation avance de la reimplementation des methodes syivantes - CheckOperandsDefinition - CheckOperandsFamily KWDerivationRule - CheckOperandsDefinition - correction specifuque pur le cas avec nombre variable d'operande, de type Unknown dans la regle enregistree KWAttribute::Check - correction pour accepter un dictionnaire de sous-table ou sous-entite sans cle, s'il n'est pas natif, et s'il ne s'agit pas d'une règle de référence à une table externe - si l'attribut de type relation est calcule, soit par une regle de creation de table, soit par une regle quelconque, la cle n'est plus obligatoire Parser KWCYac.yac - corrections mineures pour la gestion des operandes en sortie KWDRBuildTableAdvancedView - utilisation d'un nombre variable d'operandes a la fois en entree et en sortie pour les alimenations de type calcul Tests extensifs des methodes BuildTableView et BuildTableAdvancedView - LearningTest\TestKhiops\z_TableCreationRules\TableRenameVariables: test de quatre facons de renommer les variables d'une sous-tables
…d multi-table schema
Lors de la construction de variable pour un schema multi-table, une passe de collecte des echantillons de valeur
est necessaire pour instancier les operande de slection de la regle construite TableSelection.
Cela se fait dans le cas d'un schema multi-table "logique" avec un mapping sur un ensemble de fichier.
Avec les regles de creation de table, on peut avoir un schema "logique" mono-table avec construction
en memoire d'une structure multi-table selon un schema "conceptuel".
C'est le cas par exemple dans le cas d'une serie temporelle de taille fixe representee par une serie de variableq
Value_1, , Value_2, Value_last que l'on peut representer via une table secondaire via un dictionnaire comportant
des regles de construction d'entite et de tables
- TS_i = BuildEntity(i, Value_i : Index, Value) par valeur de la serie
- EntitySet(TS_1, TS_2,...)
Il s'agit ici d'etendre les algorithmes de collecte d'echantillons de valeur dans le cas de schemas multi-table "conceptuels"
cree a partir d'une reprentation mono-table "logique".
KDSelectionOperandSamplingTask
- extension au cas ou la base utilisee est mono-table (avec representation multi-table "conceptuelle")
- on s'adapte maintenant au cas mono-table, avec acces aux specificites multi-tables uniquement si necessaire
- on accede a la datrabase de facon generique, avec acces au cas multi-table uniquement si necessaire
- ComputeResourceRequirements: extension des heuristique de dimensionnement au cas d'un schema multi-table construit
- on peut avoir une base mono-table avec des Table ou Entity crees par des regles de creation d'instances
- dans ce cas, adaptation de l'heuristique de dimensionnement basee sur une estimation du nombre max d'objet en memoire
- on prend en compte les instances creees par des regles de creation d'instance
- ComputeCreatedEntityNumber: calcul du nombre de variable de type Entity crees par des regles
KWDatabase, KWMTDatabase
- deplacement des methodes de gestion des attribut de type Realation en Unused a garder pour gerer
correctement leur mutation
- nkdUnusedNativeAttributesToKeep: dictionnaire impacte
- methodes deplacees de KWMTDatabase vers KWDatabase
- ComputeUnusedNativeAttributesToKeep
- ComputeUnusedNativeAttributesToKeepForRule
- autres methdoes impactees
- BuildPhysicalClass: supprimees de KWMTDatabase et enrichies dans KWDatabase
- DeletePhysicalClass
PLSTDatabaseTextFile: ajout de methodes de dimensionnement similaire a celle du cas multi-table
- GetInMemoryEstimatedFileObjectNumber
- GetEstimatedUsedMemoryPerObject
PLDatabaseTextFile: acces generique aux methodes de dimensionnement, pour les deux cas mono et multi-tables
- GetInMemoryEstimatedFileObjectNumber
- GetEstimatedUsedMemoryPerObject
Ce type de probleme etait correctement diagnostique, mais le dictionnaire erronne etait quand meme charge en memoire, ce qui ne permet pas au traitements (apprentissage, déploiement) de s'executer correctement. En effet, la methode Check verifie tous les types d'erreur, sauf la detection de cycle qui n'est detectee qu'au moment de la compilation d'un domaine, qui est lie a la detection de cycles. Correction: - KWClassDomain::Compile: cette methode renvoie desormais un booleen en cas d'erreur dues a des cycles dans le graphe des regles de derivation - en cas d'erreur, le dictionnaire n'est pas charge en memoire, empechant tout traitement - impacts dans - KWClassManagement::ReadClasses, pour Khiops et Khiops coclustering - KNIOpenStream, pour l'ouverture d'un stream KNI, qui desormais echoue
Extension de la detection de cycle dans les dictionnaires au cas de cycle de creation d'instance,
qui peuvent aboutir a une recursion infinie de creation d'instances
Impacts:
- KWDRRelationCreationRule::ContainsCycle
- extension de la detection de cycle dans le cas d'un attribut lie a une regles de creation de table
- dans ce cas, on analyse tous les attributs de la table cree
// On propage la detection de cycle au dictionnaire des instances creees en sortie, qui potentiellement
// pourrait creer des instances en boucle infinie
// Il n'est pas par contre necessaire de detecter les cycles de calcul sur les attributs sources de vue
// dans le cas d'une alimentation de type vue, car cette detection est de toute facon effectuee
// pour chaque dictionnaire
- KWDerivationRule::ContainsCycle
- amelioration mineurs des messages d'erreurs existants
Autres ameliorations ou correction mineures
- KWDerivationRuleOperand::CheckCompleteness
- completion dans le cas d'operande en nombre variable et de type Unknown, dans le cas d'attribut inexistant
- KWDRRelationCreationRule::CheckOperandsCompleteness
- supression des '"' autour des noms de variables et de dictionnaire, qui alourdissent les message d'erreur
et ne sont pas conformes au reste des messages
- KWDRRelationCreationRule::CheckOperandsFamily
- correction sur le controle de coherence de type entre operandes en entree et sortie dans le cas de type relation
- KWDRRelationCreationRule::FillComputeModeTargetAttributesForVariableOperandNumber
- correction dans le cas des attributs de type Entity
- KWAttribute::ContainsCycle, KWAttributeBlock::ContainsCycle
- on conditionne la detection de cycle a la presence d'une regle de derivation, pour eviter des traitement inutiles
- on remplace un SetAt(key, NULL) par un RemoveKey(key) pour etre plus effcace en memoire
Plus quelques typos de commentaire
KWDRRelationCreationRule
- clarification des comemntaire sur l'utilisation des cles et de Root pour les dictionnaire des tables creees par des regles
En resume:
- un dictionnaire peut ne pas avoir de cle s'il est cree
- verification a priori lors de la lecture d'un fichier dictionnaire
- verification des cles pour les variables natives (non calculee) de type relation
- contrainte uniquement si le dictionnaire utilisant a une cle
- cree une contrainte sur la table calculee
- peut ne pas avoir de cle
- si elle une cle, ses sous-table doivent egalement en avoir
- verification a posteriori sur l'usage d'une flocon via le choix d'une dictionaire d'analyse
- ok si coherence des cle, permet la lecture a partir de fichier
- ko si des variable natives ne peuvent etre lues en rasion d'un manque de cle
- gestion des tables externes (Root)
- interdiction de creer une table associee a un dictionnaire externe (Root)
- sinon, incoherence de la gestion des references au objets externes, non rpesents dans des fichiers
- attention, lors de l'analyse recursive d'une dictuionnaire d'analyse
- on se limite aux table natives pour en deduire le flcon
- il faut par contre parcourir entierement les tables calculees ou non pour en deduire les tables externes a utliser
Impacts
- interdiction de creer une table Root
- KWDRRelationCreationRule::CheckOperandsCompleteness
- correction pour prendre en compte les regles associees a des blocs d'attributs
- KWAttribute::GetReference
- tolerance sur la verification des cles
- KWAttribute::Check
- amelioration des messages d'erreur et de warning
- KWAttribute::Check
- KWClass:CheckClassComposition
- extension en prenant en compte les tables externes references depuis des attributs table creees par des regles
- KWClass::ComputeOverallNativeRelationAttributeNumber
- KWMTDatabase::CreateMapping
Problemes apparaissant avec des schema en flocon est des vues
- detecte dans z_TableCreationRules\NoKeyInCreatedSnowflake
- variantes selon CheckDatabase, Compute, avec plus ou moins de constructed features
- exemple, flocon: Customer-Service-Usage
- Vue ServiceView sur Service, avec recuperation des usages
- Services en Unused:
- destruction des Usages depuis Services, ce qui les rend inutilisables depuis les ServiceView
Autre probleme: jeu de test TestKhiops\z_TableCreationRules\BugDeleteSubTableOfView
- apprentissage avec creation de variables
Bilan
- les corrections ci-dessous permettent de resoudre tous les problemes connus
- la trace est maintenant suffisante pour identifier les problemes de gestion memoire
- il va falloir par contre optimiser la gestion des classe phtsique dans KWDatabase pour oiptiiser les calculs dans le cas de vues
- gestion non optimale des attributs utilises pour le calcul de la classe logique par KWDatabase
- cf. KWDRRelationCreationRule::BuildAllUsedAttributes
Tentative abandonnee de gestion automatique de la memoire par comptage de reference
- KWObject: mise en place de la gestion des references
- longint lRefCount
- SafeReferenceObject, SaveDeleteObject
- idem pour tableau d'objets et bloc sparse de tableaux d'objets
- utilisation dans KWObject des methodes SafeReference* et SafeDelete*
- ComputeAllValues
- DeleteAttributes
- CleanTemporayDataItemsToComputeAndClean
- CleanAllNonNativeAttributes
- CleanNativeRelationAttributes
- Mutate
- KWClass: nettoyage de la gestion des UnloadedOwnedRelationAttribute
- GetUnloadedOwnedRelationAttributeNumber: supprime
- GetUnloadedOwnedRelationAttributeAt: supprime
- GetTotalInternallyLoadedDataItemNumber: a supprimer
- impacts sur KWObject: DeleteAttributes, Mutate, GetUsedMemory
- KWDatabase: nettoyage du calcul des attributs a garder
- BuildPhysicalClass: calcul des attributs a garder commente
- supression de ce parametre a propager
- ComputeUnusedNativeAttributesToKeep: a suprimer
- ComputeUnusedNativeAttributesToKeepForRule: a supprimer
- abandon car cela ne marche pas a cause des cycle de references potentiels
- cf. graphe de donnees, base de molecules
KWDatabase::BuildPhysicalClass
- quand on reordonne les attribut physique surnumeraire en fin de classe, on ne deplace ceux
qui etaient utilises dfans la classe logique
- par exemple: besoin d'un attribut natif used d'un classe en unused, mais en source d'une vue
KWDatabase::ComputeUnusedNativeAttributesToKeepForRule
- on prend on compte toutes les variables de type relation, quelle que soit leur nature
- avant, on se limitait aux operandes relations de même type que celui du code retour de la regle
- cela ne suffit pas pour les regles de creation d'instances
- on prend maintenant en operande l'ensemble des classes necessaires recursivement dans le flocon
- on garde ainsi tous les attributs crees associes a un dictionnaire necessaire
- resout le cas d'un dictionnaire utilise pour calculer une vue, mais jamais directement utilise sinon
Correction mineure additionnelle
- Bug dans les mappings multi-table avec des variables de type relation dont le nom est de longueur 1
- Bug d'assertion dans le mapping multi-table pour un nom de variable de un seul caractere en fin de data path
- Bug d'effet de bord
- Correction dans KWMTDatabaseMapping::CheckDataPath
Amelioration de la trace pour aider au diagnistique des probleme de gestion memoire des KWObject
- KWMTDatabase::UpdateMultiTableMappings: ajout de trace
- KWDatabase::BuildPhysicalClass: stabilisation de la trace
- tri des classe
- tri des attributs par classe, puis par nom
- impact avec KWAttributeCompareClassAndAttributeName
- variante de KWAttributeCompareName avec comparaison prealable du nom de la classe
- KWDatabase::MutatePhysicalObject: ajout de trace avant et apres mutation
- KWObject::PrettyWrite: version de Write avec indentations
- KWObject: ajout de trace pour la mise au point fine des mutations d'objets
- ComputeAllValues
- DeleteAttributes
- Mutate
Tests complets sur \z_TableCreationRules en debug
marcboulle
force-pushed
the
199-extend-derivation-rules-to-create-new-instances-of-table-or-entity
branch
from
1d23f2b
to
913a58a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Première version de l'implémentation des règles de création d'instance
Objectif du merge
Objectif du review: