old register metadata update of database (re3gistry 1.3.1)

[jane-heller-bkg]

Hello everyone,

currently I am trying to deploy changes to metadata of registers for customers (eg. name, description, contact) in a re3gistry version 1.3 instance. That mainly involves changes to records in the localization table of the main database. However, if I do changes to that table, the changes are never propagated to the static files, determined for the deployement. For example if I change the name of a register from Codelists of A to Codelists of B, in any case Codelists of A is written to all the export files which contain the metadata anyways.

I have tried pretty much everything from searching the complete database for old remainders of former descriptions at places that might be not documented to searching the whole webserver root for old remaining description fragments. I frequently deleted the '/mnt/convertedFiles' folder, where the export files are generated and even did a full database export over the last night, without success. Also I created blank clarifications on the changed registers and also changed the metadatas timestamps in the localization table to newer dates - without success.

As I did not find any more information in the documentation either, maybe you can point me out, which intermediate step in the proccess I could have overseen. I would be glad to get some support on that, as I have to finish a lot of requests for that deployment at the moment.

Best regards

Jane

[emanuelaepure10]

Hi @jane-heller-bkg

Doing a change in the database will never propagate to change a file in the filesystem.

The actions that can be done in a register/item are editing (we call it clarification, is why you want), supersession, invalidation or retirement.

You should take the .csv file that you have imported with the Codelist A, take the line referring to it, put it in a clarification.csv containing the same header that you have used for the addition.csv and just remove from the header the "status" column.

Than import this file in the backend and this will propagate the changes in the files. the Codelist A will become an older version for the Codelist B.

but if you would manage to migrate to the new version all this problems will disappear. In the new version the backend has a very nice management system of the items and just by one click you will have all the editing done and all the frontend updated.

Let us know what you decide I would really try the succeed the migration and have no such problems in the future Emanuela

[jane-heller-bkg]

Hello Emanuela,

thanks for your feedback.

The actions that can be done in a register/item are editing (we call it clarification, is why you want), supersession, invalidation or retirement.

You should take the .csv file that you have imported with the Codelist A, take the line referring to it, put it in a clarification.csv containing the same header that you have used for the addition.csv and just remove from the header the "status" column.

Than import this file in the backend and this will propagate the changes in the files. the Codelist A will become an older version for the Codelist B.

Just to sum that up if I get that correctly. To do changes on the register metadata, i would have to:

1. change the register metadata in the database
2. create a copy of the last codelist addition
   • (or do you mean the first codelist addition, or all codelist additions in general, or an arbitrary codelist addition to that register?)
3. remove the column status
4. rename the file from @addition.csv@ to @clarification.csv@
5. import the file

Should it still contain any data, or just the header?

but if you would manage to migrate to the new version all this problems will disappear. In the new version the backend has a very nice management system of the items and just by one click you will have all the editing done and all the frontend updated.

Thanks for the tip. I would like to try that out, as soon as we get a test instance running with that version.

Best regards

Jane

[emanuelaepure10]

Hi @jane-heller-bkg

You should never change the database by itself. The change will never be propagated anywhere.

I have attached an example for a MetadataCodelist and MetadataCodelistValue Use then as you have used the addition files. Go to the backend and upload the zip after you have filled with the correct data.

MetadataCodeAndMetadataCodeListValue.zip

Let us know if you have any problem I would still underline that would be better if you would manage to migrate your data to the new version of the software.

Emanuela

[jane-heller-bkg]

Hi Emanuela,

I have attached an example for a MetadataCodelist and MetadataCodelistValue Use then as you have used the addition files. Go to the backend and upload the zip after you have filled with the correct data.

MetadataCodeAndMetadataCodeListValue.zip

Thanks for the example but if I get that right, this is just for changing data contained in the register (ie. Codelist data or codelist metadata)? What I wanted to do is to change metadata of the register itself.

Maybe I did not explain myself clear before: In the process for creating new registers we define a set of SQL statements which contain register metadata, eg. the name of the register itself, the control body, contact information and so on. These statements generate new records in the tables reference, register, localization and itemclass. Now I have the case, that customers want to change those data and another case where a customer provided data which is not correctly escaped by re3gistry so I have to change it after the initial creation of the register by populating those SQL records to the database. The specific data I want to change is contained in the table localization where it refers to the register itself. This process is also specified in your documentation of re3gistry in section 3.4.2. (p. 37ff).

You should never change the database by itself. The change will never be propagated anywhere.

If I should never change those initial register information in the database itself I need information on how to change that specific data in another way. I could not find any information in the documentation about that.

Let us know if you have any problem I would still underline that would be better if you would manage to migrate your data to the new version of the software.

I just replied to #68 as I was still not able to find any logging information about the migration process and hence could not proceed on that in any way. But I just sent you a personal mail w.r.t. to debugging etc.

Best regards

Jane

[oscar9]

Hi @jane-heller-bkg ,

One possible bug has been found during a 1.3.1 to 2.x migration from other user in issue #218 . We will try to replicate this error and keep you informed. Please, if you still have your logs available, check for the re3gistry2.log file.

Thanks

[jane-heller-bkg]

Hi @oscar9,

thanks for your message. Maybe you got the wrong ticket here? This was a ticket about changing a registers metadata within the old 1.3 branch. I replied w.r.t. the migration issues to ticket #68

Best

Jane

[jescriu]

After having analysed this issue, it refers to changes performed in the database which does not directly form part of the Re3gistry logic itself, which at the same time may prevent a successful migration to version 2 of the software.

Furthermore, it refers to version 1.3 of the software, which is currently not in the scope of the maintenance work currently dealt by our contractors.

For this reason the JRC INSPIRE team has decided to wait for the upcoming discussion on the future of the Re3gistry open-source software, the scope of the support to users and the funding available. For the above-mentioned reason, this item is temporarily closed.