dumpers: support for different load type #274
Conversation
| @@ -169,12 +169,11 @@ def _load_model_field(self, record_cls, model_field_name, dump, dump_key, | |||
| return val | |||
|
|
|||
| # Determine dump data type if not provided | |||
| if dump_type is None: | |||
| sa_field = getattr(record_cls.model_cls, model_field_name) | |||
There was a problem hiding this comment.
@slint this is the "bug" @alejandromumo discovered. This variable is never used, we could potentitally just return it, but then we would lose the capability of custom serializations, which is what we (and in most of the cases want).
|
Discussed IRL, check if it can be achieved with |
* Test should fail, as it is not allowed to load/dump with different types.
| assert isinstance(dumped_data["test"], str) | ||
| # Deserialize | ||
| loaded_data = dumper.load(dumped_data, TestRecord) | ||
| assert isinstance(loaded_data.test, EnumTestModel) |
There was a problem hiding this comment.
This is currently failing, as the data is being loaded as a str and not EnumTestModel. That happens because record's ModelField test has the attribute dump_type set to str when instantiated. Therefore, the load_type will be also set to str and does not allow the dumper to infer the load type from the record's model SQL Alchemy column type.
See dumper's load module field:
invenio-records/invenio_records/dumpers/elasticsearch.py
Lines 164 to 176 in 1271fd7
There was a problem hiding this comment.
Just to clarify, this is an issue with the master branch, independently of the previous commit or not (dump_type parameter rename to load_type).
|
This is still relevant for consitency. However, the pid status got dropped from the implementation so we do not need it even in the far future. Might be shelvable |
|
@alejandromumo Can you check if this is still needed? If yes, add it to our ops board to work merge an integrate, and if not simply close. |
closes #276