Hi All,
Just writing a note in case anyone runs into this issue. I don't know the
root cause of what happened, the logs were 90 days ago, and we don't keep
that far back.
Symptom, can't create a new eperson.
java.lang.NullPointerException
at org.dspace.eperson.EPerson.searchResultCount(EPerson.java:438)
at
org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:118)
Further digging shows that there is no metadata schema registry for the new
registries in DSpace 5. dcterms, eperson, workflow.
Also, I noticed that
select * from metadatavalue where metadata_field_id is null;
Had results (32 rows, I feel lucky it wasn't in the thousands, only a few
users in this repository) and resource_type_id was all 7, which is EPERSON.
So the new metadata registries didn't get created, and the eperson metadata
did get moved from the eperson table to metadata4all's metadatavalue.
Checking Flyway, showed that the database migrations were all successful.
I fixed this by manually running a job to create the metadata registries.
bin/dspace registry-loader -metadata config/registries/dcterms-types.xml
bin/dspace registry-loader -metadata config/registries/eperson-types.xml
bin/dspace registry-loader -metadata config/registries/sword-metadata.xml
bin/dspace registry-loader -metadata config/registries/workflow-types.xml
I then used navicat postgres to query all of these null metadata values,
and then navicat is REALLY nice in that you can just click a value, change
it, and it will automatically update. (Maybe phpmyadmin has some nice thing
like that too, but different language, different tool).
select * from metadatavalue where metadata_field_id is null order by
resource_id asc;
SELECT
metadata_field_id, element
FROM
public.metadataschemaregistry,
public.metadatafieldregistry
WHERE
metadataschemaregistry.metadata_schema_id =
metadatafieldregistry.metadata_schema_id AND
metadataschemaregistry.short_id = 'eperson';
127;"firstname"
128;"lastname"
129;"phone"
130;"language"
Then you'll have to set things that look like "Peter" to have
metadata_field_id = 127
"Dietz" to 128, "en" to 130, and phone numbers to 129.
I don't have the old upgrade logs to see what caused this. If there perhaps
was an error thrown during the upgrade. There's a small chance this
instance had some custom changes to its data model, I can't recall. But,
just posting this on dspace-tech, so that someone can eventually find it in
their search results.
________________
Peter Dietz
Longsight
www.longsight.com
pe...@longsight.com
p: 740-599-5005 x809
--
You received this message because you are subscribed to the Google Groups
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at http://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
