Raising an issue: Char length of volume

Software Support
1

Dear all,

I’d like to raise an issue:
The length of the volumes (in issues) in OJS is limited to 10 characters (c.f. line 175 in https://github.com/pkp/ojs/blob/master/dbscripts/xml/ojs_schema.xml) “<field name="number" type="C2" size="10" />”

Usually before, I’ve always hacked the size to 255 chars in the db and for upgrades I changed “dbscripts/xml/ojs_schema.xml”, in order to be able to better grasp the title of an issue (although I am aware that this is not the intention of the way issues and numbers are related to each other). All of that, just because the title of an issue is rarely displayed in the distributed metadata (e.g. DOIs).

Having a look into the schemes of datacite and crossref (as for DOIs), I do reckon that the field size is either not limited at all in case of datacite (@mfenner: could you please confirm or falsify?) or limited to 32 chars in case of @crossref (c.f. Schema documentation for namespace http://www.crossref.org/schema/4.4.2)

Now, that is just one place where the size of the field is controlled. From time to time - and I do not know where it happens - my hacks are being trunkated again to 10 chars in the db. (not that I am annoyed, just wondering and doing changes in the db AGAIN - please bare with me)

Would it be possible to harmonize the size and to identify places where this value is either set to NULL by default or is being truncated in the form fields of the core app?

Thank you so much for your understanding and support
Klaus

PS: OJS is the geatest !

2

Hi @klausru,

The length of the Volume field is specified (as you’ve noted) in dbscripts/xml/ojs_schema.xml; there is a markup-based limit of 40 characters in templates/controllers/grid/issues/form/issueForm.tpl (these lengths should definitely be synchronized, or at least the database length kept longer, or visiting the form will result in data between 10 and 40 characters being chopped short).

I’m not sure how the database field could be getting reset to 10 characters unless the ojs_schema.xml change is reverted and then the upgrade script is executed. Otherwise OJS shouldn’t alter these.

Can you describe the kind of data you’re putting into this field? Typically it’s a very short number.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
3

Thanks @asmecher for having a look at this.
I was entering plain text into this field, knowing that describing volumes with char-text issues is not the intended way, but anyway …
Without further investigation, I do have the impression that the dashboard form for manupilating issue data does carry its own standard field entries (e.g. filling NULL with “0”) etc. That might be harmonized as well.

All the best
Klaus

4

Hi @klausru,

I think the problem of casting empty fields to 0 may have already been fixed recently… What version of OJS are you using?

Regards,
Alec Smecher
Public Knowledge Project Team

5

In my sandbed I am currently testing 3.1.2-4 and preparing to upgrade to 3.2. My production environment is still 3.1.1-4

6

Hi @klausru,

I’ve extended the length of the number column to 40 to match the form’s maxlength attribute. This change will be first released in OJS 3.2.

The “Number” field had a recent issue where it was getting filled in with 0 when left empty, but that should already be fixed – see [OJS] Updating issue without volume results on 0 on database · Issue #1375 · pkp/pkp-lib · GitHub.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
7

This is great, thank you so much.
I am really looking forward to upgrading.
Did I ever say that I am fan of OJS?
I am: https://doi.org/10.5281/zenodo.3238457

Best regards
Klaus

1 Like
8

…this is very cool!

1 Like
9

Hi @klausru,

Agreed, very cool! I’ve sent that around our team.

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like
10

Hi @asmecher
after I succeeded in delivering all volume data to Crossref (see here: Export all avail data to Crossref) I realise that the number column MUST NOT exceed 32 chars - that is: including special chars like those German umlauts (ä, ö, ü). Even after I set the maxlength of the column to varchar(32) in the database I received error messages from Crossref. Just from counting the chars it means that (ä, ö, ü) count double. This also means that their server (probably handle.net) might not operate in utf8.

This is the error msg:

org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [INSERT INTO atypon.citation_info (CITATIONID, JOURNALCITEID, BOOKCITEID, SERIESTITLEID, MISSPELLINGID, SUBMISSIONID, VERSION, YEAR, VOLUME, ISSUE, SUPPLEMENT, PAGE, AUTHOR, COMPONENTNUMBER, EDITIONNUMBER, OWNERPREFIX, ARTICLETITLE, SEQUENCENUMBER, TYPE, DOI, MDCONFLICTID, PAGEMOD, SRCTYPE, ORIGPAGE, LASTPAGE, PUBMONTH, PUBDAY, CONFNAMEID, INSTCITEID, FORCEDALIASID, ALIASID, SRCSUBTYPE, LASTUPDATE, REFSUBMISSIONID, MASK) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; SQL state [72000]; error code [12899]; ORA-12899: value too large for column “ATYPON”.“CITATION_INFO”.“ISSUE” (actual: 33, maximum: 32)

; nested exception is java.sql.SQLException: ORA-12899: value too large for column “ATYPON”.“CITATION_INFO”.“ISSUE” (actual: 33, maximum: 32)