Hi Florent,
it is a matter of about 170 metadata.
Another possible solution could be to change for each metadatafileuploads the ID accordingly
with the ID in the metadata, then change the identification number of each metadata_data folder.
I don't know how long does it take this process, considering the possible problems on foreign key...
Maybe the only solution is to upload again the associated resource....sigh...
Eugenio
________________________________
Da: Florent Gravin <florent.gravin@anonymised.com>
Inviato: giovedì 14 aprile 2022 09:01
A: Eugenio Trumpy <frippe12573@anonymised.com>
Cc: Lista Geonetwork <geonetwork-users@lists.sourceforge.net>
Oggetto: Re: [GeoNetwork-users] R: restore metadata_data to metadata
Hi Eugenio,
Yes I meant ID and not UUID, it's how resources are stored in the data_dir.
I don't really know what is the best for this usecase, never experienced it, depends on how many metadata you have ?
Changing the id in the database my not be the best because of relations and constraints with foreign key, the safer would be to clean your data directory and upload again the attachement, if you don't have too many.
On Thu, Apr 14, 2022 at 12:54 AM Eugenio Trumpy <frippe12573@anonymised.com<mailto:frippe12573@anonymised.com>> wrote:
Hi Florent,
thank you for your hint, my external data directory works fine and is well reported in the dashbord.
So I deeply checked the relations between the metadata uuid and metadataid in the metadata and metadatafileuploads tables respectively.
Unfortunately I discovered that the data directory I restored (which is the only one I have because I didn't have a very update backup)
contained the associated resources but the metadataids don't match properly the metadata id even if each uuid is the same in the metadatafileuploads filename field and the metadata identifier.
I don't know which is the quickest way: i) to sort out the ids in the db or ii) I should upload again the associated resources for each metadata.
Any suggestion?
Cheers,
Eugenio
________________________________
Da: Florent Gravin <florent.gravin@anonymised.com<mailto:florent.gravin@anonymised.com.>>
Inviato: mercoledì 13 aprile 2022 20:00
A: Eugenio Trumpy <frippe12573@anonymised.com<mailto:frippe12573@anonymised.com>>
Cc: Lista Geonetwork <geonetwork-users@lists.sourceforge.net<mailto:geonetwork-users@lists.sourceforge.net>>
Oggetto: Re: [GeoNetwork-users] R: restore metadata_data to metadata
Hi,
Did you check the path of your data_dir in your new instance ?
In admin / statistics and status / information
admin.console#/dashboard/information
What do you see for all the paths in catalog information ?
If the metadata have been restored with the same uuid, then geonetwork should be able to find the attached resources if the path is correct.
Hope it helps
On Wed, Apr 13, 2022 at 6:56 PM Eugenio Trumpy via GeoNetwork-users <geonetwork-users@lists.sourceforge.net<mailto:geonetwork-users@anonymised.comnet>> wrote:
Hi everyone,
I'm still struggling with the metadata associated data (i.e., thumbnails, datasets, ...).
As described in my previous message, I'm trying to restore the associated data to each metadata,
after that tomcat re-deployed geonetwork due to a memory leak.
Now I have esternalised the data directory, I restored the db connection to geonetwork,
I sorted out all the look&feel customization.
What is still missing is the link between the metadata and associated resources.
I checked the data directory I used from a backup copy I had and I saw that associated resources are available
in their respective folders. Then I controlled in the 'metadatafilesupload' table in the DB that the resources
are linked to the correct metadata ID. Everything seems to be ok, but if I try to download the resource from
the link I got this error:
Metadata resource 'my_dataset_.csv' not found for metadata '647aa042-8bbf-4a1c-a2f6-6947d0f28d7b'
which is very strange.
The chrome devtools (in the console) I see:
Failed to load resource: the server responded with a status of 400 ()
[Violation] 'setTimeout' handler took 60ms
Do you know the reason?
Is there a way to restore the linkage?
This issue is on GN 3.6.0.0
Regards,
Eugenio
________________________________
Da: Eugenio Trumpy
Inviato: mercoledì 6 aprile 2022 00:53
A: Lista Geonetwork <geonetwork-users@lists.sourceforge.net<mailto:geonetwork-users@lists.sourceforge.net>>
Oggetto: restore metadata_data to metadata
Hi all,
unfortunately I had a memory leak in my tomcat, so it 'decided' to
re-deploy the geonetwork.war overriding all my data directory.
My mistake was not to externalise my data directory, so I lost
all the configuratin and metadata_data (files appended as the thumbnails
and the uploaded datasets).
Fortunately, I found a not so old backup including a geonetwork.war and
the relate deployed geonetwork folder from which I restore the data dir.
However, I suppose that the backup was not at the same version of the running
geonetwork. It means that the running was GN 3.6.0 and the backupped deployed
geonetwork folder was GN 3.4.
So now I have my GN 3.6 running but all the appended files to the metadata are not
available although they are existing in the metadata_data folders.
Is there a way to link the UUID of the metadata to the folders named xxxxxx-yyyyyy
or the only way is to adjust metadata by metadata uploading again thiumbnails
and associated files?
Actually, I have another issue: the spatial extent although it is set is not displayed,
and the browser console report a runtime 'nullpointexception' error.
Any hint about these two issues?
Cheers,
Eugenio
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users@anonymised.comforge.net>
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
--
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Florent Gravin
Technical Leader - Architect
+33 4 58 48 20 36
--
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Florent Gravin
Technical Leader - Architect
+33 4 58 48 20 36