Error when importing: 'Null value in email column'

I’m migrating a journal across to another instance of OJS using the Articles & Issues XML Plugin. After uploading an issue, I receive the following error message:

DB Error: ERROR: null value in column "email" violates not-null constraint

Stack Trace:
File: /var/www/journals/classes/article/AuthorDAO.inc.php line 170
Function: DAO->update("INSERT INTO authors (submission_id, first_name, middle_name,...", Array(9))

File: /var/www/journals/plugins/importexport/native/NativeImportDom.inc.php line 967
Function: AuthorDAO->insertAuthor(Object(Author))

The obvious thing to check, it seems, is that the original issue did not have any blank entries in any email fields, but I haven’t found that to be the case. Are there any other required fields that could be generating this error, or something else that I might not have considered?

The issue data uploads but none of the articles do. For other issues that give the same error, a handful of articles plus the issue data will successfully upload. (The same articles always fail on subsequent import attempts, even after re-exporting the XML from the original.)

We’re running version 2.4.2.0.

Hi @hcmcf,

Agreed, this looks to me like an empty or missing <email> element within an <author> element. Have you tried validating the XML?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,
The XML validates fine. I discovered a missing email address for a secondary author which I’ve fixed, but have a new error now:

DB Error: ERROR:  invalid input syntax for integer: ""

Stack Trace:
File: /var/www/journals/classes/article/SuppFileDAO.inc.php line 245
Function: DAO->update("INSERT INTO article_supplementary_files (remote_url, file_id...", Array(7))

File: /var/www/journals/plugins/importexport/native/NativeImportDom.inc.php line 1322
Function: SuppFileDAO->insertSuppFile(Object(SuppFile))

File: /var/www/journals/plugins/importexport/native/NativeImportDom.inc.php line 894
Function: NativeImportDom->handleSuppFileNode(Object(Journal), Object(XMLNode), Object(Issue), Object(Section), Object(Article), Array(0), False, Object(ArticleFileManager))

…goes on for a few more File/Function combos.

I suppose this is another null field that is a required field in 2.4.2.0, that was not a required field in 2.1.0.1, the version we’re migrating from.
Is there a list of fields that changed from not-required to required between these versions?

Or, any idea which field the above error is referring to - this one’s less obvious to me. An missing required field in a supplementary file?

Hi @hcmcf,

I suspect that’s the type attribute to the supplemental_file node. But if you want to check for sure, try briefly turning on debug just before importing the XML document; that’ll cause OJS to dump every database query it runs, and the last one in the list will be the problematic query. You can examine that to identify which submission is the problem.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

If the supplementary file type is selected as ‘Other’, does that make the ‘Specify other:’ field mandatory? I think this might be the problem…
If that field is blank the user can still Save the supplementary file in the UI, but could it cause an error importing XML without the Specify other filled?

(Otherwise, where do I go about turning on debug?)

Thanks for your help

Debug is in config.inc.php, right? I don’t have access to that at the moment, as I’m importing from the UI.

Hi @hcmcf,

Sorry, on double-checking that’s a red herring – the type attribute to supplemental_file should contain a string, not a number.

The debug setting is indeed in config.inc.php; note that you won’t want it left on, as it’ll add a debug dump to any request that comes in. However, it’s still the easiest way to track this down. Let me know if it’s not an option and I’ll have another look.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @hcmcf,

I may have just run into the problem. Try applying this patch:

Please confirm whether it solves the problem.

Regards,
Alec Smecher
Public Knowledge Project Team