OAI-PMH with datestamp updated daily on OJS 3.1.1.2

Hi all

Good tracking, @pir, I was able to duplicate the behaviour you described!

@marc, yes, we would be happy to have a PR to set a sensible last modification date on upgrade.

I’ve filed the issue here: OAI reports "now" for last modification when submission last modification date is null · Issue #6807 · pkp/pkp-lib · GitHub

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi all,
@marc after migration we had found also some issues without publish date in our OJS. We detect it because in editor’s back issues page appear as published but the issues also include the publish option and the column publish date was empty.

Getting a issue from database including published issues without publish date we discover that they comes from ojs2 from the same journals. Reviewing this journals this issues were created using ojs using Import native plugin with a custom xml file created based on the defined DTD. Issues created using xml from other installation ojs or using create/publish ojs2 option seem to be ok.

We don’t know the exact publish date for all this issues from diferent journals, so we solved it updating the creation date as 1st of january from the issue year.

Natalia

Hola Natalia,

I thought that in a decade and 50 magazines I had seen it all and then I remember your 500 journals and I feel there is still much to discover… :wink:

If the “sorrow of many” helps as a consolation… during our migration to ojs3 today I have detected a journal that came to us from another university without 840 articles. OJS3 was complaining about the 2400 review_assigments of those missing articles. And well, it doesn’t affect the published articles because they are all rejected ones, but from an historical perspective… just thinking about it is painful.

@asmecher thanks for creating the issue. Today I have the day full, but I promise I will work on this tomorrow.

Thanks you both,
m.

Hi you both.

In short: I can’t reproduce Natalia’s case in my journals, so looks like there are multiple reasons to the same error.

I tried to find NULL last_modified dates in “enrahonar” (a journal that we have in our OJS but also replicated in RACO).

I checked article_id 3 (that in ojs3 fails, setting datesamp to now), but when I check the DB, I don’t have any NULL in articles.last_modified:

imagen

And this date is correctly migrated to OJS3 at submissions.last_modified field:

imagen

@pir do you mind to confirm that those are the fields where you have NULL values?

Hi @marc

I have found the NULL values in issue table not in submissions, last_modified date for the journal issue.
Yesterday we have done some updates in this table and now OAI dates are ok.

Natalia

Ok… forget muy last post. :sweat:
Bug and workaround confirmed.

Don’t tell anybody but in my head each time you wrote “issue” in my brain it was translated to “submissions”. :weary:

I checked my “issues” table and, as you said, some issues don’t have a last_modified date.
When I change it, all works like a charm.

I will look for time to understand how the upgrade script works and make a PR, but till then, if somebody needs to fix it fast, running this query over any ojs3.x will do the job:

UPDATE `issues`
SET `last_modified` = `date_published` 
WHERE last_modified IS NULL;

Cheers,
m.

Hi all

Thanks, we run that query too.

Database changed
MariaDB [ojs]> UPDATE issues SET last_modified = date_published WHERE last_modified IS NULL;
Query OK, 27 rows affected (0.006 sec)
Rows matched: 34 Changed: 27 Warnings: 0

Some rows have been affected. But this haven’t resolved our earliest datestamp problem here Open Journal Systems

Regards
jan

Hi @trace,

Also try ensuring that last_modified is NOT NULL for all entries in submissions. Both issues and submissions can cause this problem. (See: OAI reports "now" for last modification when submission last modification date is null · Issue #6807 · pkp/pkp-lib · GitHub)

Regards,
Alec Smecher
Public Knowledge Project Team

The problem was, that we had NULL values in some date_published fields in table issues as well. Caused to XML imports years ago. So the query didn’t work in a first step. It’s all fixed now. Thanks.