8000 tools/rename_subject_id: incompatible with current installation (3.4.6) · Issue #464 · eprints/eprints3.4 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

tools/rename_subject_id: incompatible with current installation (3.4.6) #464

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.

Sign up for GitHub

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

Jump to bottom
Open
tgoeg opened this issue May 12, 2025 · 4 comments
Open

tools/rename_subject_id: incompatible with current installation (3.4.6) #464

tgoeg opened this issue May 12, 2025 · 4 comments
Assignees
@drn05r
Labels
bug Something isn't working
Milestone
3.4.x

Comments

@tgoeg
Copy link
Contributor
tgoeg commented May 12, 2025

After adapting the include path on its first line to point to /opt/eprints3 the script generally runs. (Some kind of relative path would be nice, but I am not versed in Perl, a simple -I../perl_lib did not work)
However I get an error:

Bareword "EPrints::Database::SQL_INTEGER" not allowed while "strict subs" in use at /opt/eprints/perl_lib/EPrints/DataObj/Cachemap.pm line 366.
Bareword "EPrints::Database::SQL_NOT_NULL" not allowed while "strict subs" in use at /opt/eprints/perl_lib/EPrints/DataObj/Cachemap.pm line 366.
Compilation failed in require at /opt/eprints/perl_lib/EPrints.pm line 289.
BEGIN failed--compilation aborted at /opt/eprints/perl_lib/EPrints.pm line 289.
Compilation failed in require at /opt/eprints/perl_lib/EPrints/Database.pm line 97.
BEGIN failed--compilation aborted at /opt/eprints/perl_lib/EPrints/Database.pm line 97.
Compilation failed in require at tools/rename_subject_id line 3.

I tried to change
use EPrints::Database to use EPrints::Database qw(:sql_types) as I found this in the wiki, but to no avail. EPrints.pm already has it, perl_lib/EPrints/Database/mysql.pm did not have it, so I added it there as well, but it still does not work.

What does work is if I change use EPrints::Database to use EPrints in tools/rename_subject_id, but I don't know if this is the correct way to fix this.
@tgoeg
Copy link
Contributor Author
tgoeg commented May 12, 2025

Spoke too soon, this script seems to need an update generally.
The tables it tries to operate on, archive_subjects, deletion_subjects, buffer_subjects, inbox_subjects do not exist on my installation.

@tgoeg tgoeg changed the title tools/rename_subject_id: Bareword EPrints::Database::SQL_INTEGER not allowed tools/rename_subject_id: incompatible with current installation (3.4.6) May 12, 2025
@tgoeg
Copy link
Contributor Author
tgoeg commented May 12, 2025

Looked into it a little further.

  • It seems the most important table is eprint_subjects. That would need modification.
  • The access table clearly would not reflect the new subjects (and I am unsure whether it would be wise to change that in retrospect?).
  • IRStats2 would most likely lose statistics for the accessed eprints.
  • The triple table (that contains octuples :-)) is a mystery to me and I don't know whether it could be regenerated (and how) or whether it would need an update, too.

It does not seem to be a straight forward change to me. But maybe some dev with more insight into the DB structure could chime in.

@drn05r
Copy link
Contributor
drn05r commented May 17, 2025 •
edited
Loading

Renaming subject IDs is general a bad idea unless you do it straightaway after you spot a typo or similar. This is why there is the machine-readable subject ID and a separate human-readable subject name (i.e. label) that can be changed without any implications.

  • A functional tools/rename_subject_id would need to update any field that is a MetaField::Subject. The eprint_subjects table (used by the eprint data object's subjects fields is the most obvious example but the eprint divisions field is also a MetaField::Subject field. The user editperms fields also uses subjects by default, as you can restrict what an editor reviews by whether an eprint has a particular subject or division set. I don't believe any user-defined data objects use subjects.
  • The access table is not something you would want to try to update, as this could take a very long time. I think I would need to take a closer look at the the access table as I am not aware of a specific field that is MetaField::Subject. The only think that may reference a subject, that I can think of its the referring_entity_id. I think is always a URL, which could be the browse view listing page from which a user navigated. This is only used by IRStats2 to identify what category of Internal referrer it is (Browse View, Abstract Page, Latest Additions, Search or just general).
  • The triple table is a red herring. Subject is used in the sense of everything can be stored as a 'triple' (subject-predicate-object). Here subject is just a URI, as triples are a Semantic Web thing, not a subject that is a subject data object.

Having not look too closely at how it currently works, I would expect that something that can determine all fields that may contain subjects would needed and then looped through and update their use of the renamed subject. I don't think it would be too difficult to do. It could though generate a lot of work for the indexer.

@drn05r drn05r self-assigned this May 17, 2025
@drn05r drn05r added the bug Something isn't working label May 17, 2025
@drn05r drn05r added this to the 3.4.x milestone May 17, 2025
@tgoeg
Copy link
Contributor Author
tgoeg commented May 19, 2025

Alright, thanks for your quick feedback.
I'll leave the IDs as they are, so no hurry from my side.
It's just that the documentation should state that it's currently impossible to do so, or the script removed or at least amended that it does not work with current (3.4.x ?) DB structures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@drn05r drn05r

Labels
bug Something isn't working
Projects
None yet
Milestone
3.4.x
Development

No branches or pull requests
2 participants
@drn05r @tgoeg
0