Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log message when invalidating record using "isEmpty" #209

Open
mbrodala opened this issue Oct 11, 2021 · 3 comments
Open

Log message when invalidating record using "isEmpty" #209

mbrodala opened this issue Oct 11, 2021 · 3 comments

Comments

@mbrodala
Copy link
Contributor

The isEmpty transformation introduced with version 6.0 allows for dropping whole records in case a field is empty.

This is very useful but for debugging purposes and for giving feedback to the data source provider a message should be logged on every record which is dropped this way. This way it is rather easy to find the affected source records and fix them.

Right now we do this with a custom step which triggers a warning message in case a record is dropped. The record is added to the message as JSON encoded string.

@fsuter
Copy link
Contributor

fsuter commented Oct 13, 2021

You're right, this would be useful. Any suggestion about error level? Warning? Notice?

@mbrodala
Copy link
Contributor Author

Anything which is accessible at least from the log module should be fine. A cherry on the top would be a single warning in the module/CLI if there was at least one skipped record .

@fsuter
Copy link
Contributor

fsuter commented Nov 14, 2021

The patch introduces logging using External Import's debug mechanism (at "error" level). So you need to activate the debug mode and set a proper logger configuration (for the Importer class). This is similar to the logging done when dropping a record from a user function by throwing the InvalidRecordException.

Last time I looked, entries written with TYPO3's logging system to the sys_log table were not compatible with the Log module, but I haven't checked if this has changed.

I'm not marking this issue as resolved, as I think that the cherry on top you mention is a worthwhile idea, but I would like to rework the messaging mechanism (also in relation to #179).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants