Closed kitchoi closed 8 years ago
@@ master #293 diff @@
==========================================
Files 49 49
Lines 3814 3814
Methods 0 0
Messages 0 0
Branches 570 566 -4
==========================================
+ Hits 3684 3685 +1
Misses 42 42
+ Partials 88 87 -1
Powered by Codecov. Last updated by 1559e47...f0451df
Restricting keywords for a data container (e.g. by specifying a fixed set of supported keywords at the initialization) is something we have been discussing for a long time now and is related to several aspects of the SimPhoNy design (see at least issues #29, #216, #217, #223).
I continue to favour implementing this feature.
In addition, the proposed implementation with a restricted subclass of the data container and utilization of the frozenset seems elegant.
It seems to me that DataContainer
and CUDSItem
are very similar and serve similar purposes. Why not consider DataContainer as the base class for metadata classes?
I'm in favor of type and consistency checking in metadata classes and CUDS itself. IMO the functionality of create_data_container
should be merged in generated classes.
IMO the functionality of create_data_container should be merged in generated classes.
Do you mean using create_data_container
in the generated class or moving the code (def create_data_...
) to the generated class module?
My intention is for the former, so that with, say, the MaterialRelation class:
>>> material_relation = MaterialRelation()
>>> # same as material_relation.supported_parameters, but a set
>>> material_relation.data.restricted_keys
frozenset({CUBA.MATERIAL})
>>> material_relation.data[CUBA.POSITION] = (1.0, 1.0, 1.0)
ValueError: Key <CUBA.POSITION: 119> is not in the supported CUBA keywords
Your latest code example is close to what I intended and looks good to me. As long as the use of the factory method is internal, it is fine.
Just added an optional argument to the create_data_container
function for setting class name so that one can assign the dynamically created class to a (conventionally) private variable while still have pickling support.
In order to replicate the keyword checking in
MaterialRelation
(https://github.com/simphony/simphony-common/blob/master/simphony/cuds/material_relations/material_relation.py#L107) for all the generated classes from simphony-metadata, it would be more effective if the checking is done at theDataContainer
level.For example:
Performance of the DataContainer is basically the same to the one we have now. Benchmark:
(Running with Ubuntu 12 on a VM with 1 core, 2.5GHz, 4GB RAM)
Please consider this as a proposal and please comment, review or propose alternatives.