davidvlaminck / otlmow Goto Github PK

convert_to_correct_type has been implemented to convert the values as much as possible to the correct types, before trying a validation and assigning it to an attribute.
This should be implemented to be the default method of assigning values and producing a warning log (similar to using deprecated attributes) to inform, but not stop, the user from assigning an incorrect typed value to an attribute

see test_create_aimObject_using_other_aimObject_as_template_testclass()

this test fails and shows that something is wrong with the implementation of either the complex datatypes or the template function

Use args or kwargs in constructor of OTL Object to allow init with property values
This should be possible using dotnotation

generating the model should also remove all existing files/dirs of the directory first

clean up the set_waarde method of OTLAttribuut to more clearly communicate what its function is and how it works

input formats are defined with a number of parameters such a seperation chars. It is preferred to implement the input files using the same parameterization to anticipate future changes

Splitting the project into different libaries:
otlmow-model: just the model classes and dependent classes
otlmow-modelgenerator: generates models
otlmow-converter:import and export of models, additional support classes
otlmow: other support classes and features in development

when exporting using CsvExporter, there is no validation for attributes with cardinality > 1 to have the same numbers of elements in the lists of complex datatypes.

Lijsten hebben niet dezelfde lengte: [{"externePartij":"bij externe partij 1"}] + [{"externReferentienummer":"externe referentie 2"},{"externReferentienummer":"externe referentie 1"}]

All data is stored in one csv file when using CsvExporter. The user should have the choice of putting it all in one file or to have one file for each asset type.

KlAdmsStatus is a list that contains the possible values for the items of enumerations.
Reading a ttl containing those statuses is already possible, but there is no behavior attached to those statuses.

The current Geometry Artefact implementation is too strict, raising errors if the wrong type is used for the geometry of an asset. Raising a warning instead is sufficient

AllCasesTestClass is a test class used in unit tests. This should be created through a SQLite as part of the unit tests instead of being hard coded

Generate dummy data for every OTLAttribuut instance

assetId is mandatory when creating an asset

There are multiple namespaces for assets (installatie / onderdeel / implementatieelement) These are all combined in one directory and should be modified into different directories, one by namespace

Dte's and KwantWrd attributes have a waarde attribute that contains the actual value. However, in all AWV implementations of datafiles a shortcut is used. Instead the values are assigned to the Dte and KwantWrd attributes themselves as though they were the .waarde attributes. This has been correctly implemented, however the code is not clean.
A refactor of the code is needed to clearly mark the intend and to allow a change should this be needed.
It is preferred to implement true to the OTL.

When creating the model, the line that implements the class's inheritances is not properly unit tested since the existing tests do not account for the geometry artefact

refactor relations to not use one class with a list of all valid relations. Instead list non-inherited relations per class