Impex load creates record regardless of field not resolvable

[Former Member]

In hybris 5.2.0, we observed that loading a record with unresolvable field, HAC will report error, but then the record is actually created.

e.g. loading categories using impex, if the supercategories has not been created, HAC will report error, but actually the category will be created without supercategories populated.

This is really confusing behavior, that HAC displays error, but record is getting created. Some of the code indicates this is the out-of-the-box behavior that if the field is not mandatory, even the data is not resolvable, the record is still created. And this leads to bad data loaded into the system even though the log says error.

The behavior in my opinion should be if any error happens during impex load, the specific record should NOT be created and error should be reported.

[Former Member]

Yes, I understand that looks like it is the behavior per Impex API document.

However, I would like at least hybris could provide a flag to flip the behavior to be more restrictive, i.e. record should not be created if a field is not resolvable no matter it is mandatory or optional.

This issue leads to data loading, data migration issues that bad data is created even though error was reported.

Anyone from hybris can help here? It is sort of feature request.

[Former Member]

If all mandatory columns in the value line were given and successfully translated, an item is created despite the fact that maybe other non-mandatory attributes are not resolved.

https://wiki.hybris.com/display/release5/ImpEx+API

[former_member224482]

I believe this is the difference between import_strict and import_relaxed.

[Former Member]

STRICT mode won't resolve this problem. please see comment below.

[Former Member]

Robin, thx for the hint. However, I don't think the impex_strict mode will work. Per https://wiki.hybris.com/pages/viewpage.action?title=ImpEx+API&spaceKey=release5, the different validation mode only have impact to the mandatory fields no impact to the optional fields.

As stated in my comments, I would think providing a flag to flip this behavior will be a very good feature to have.