[GeoNetwork-devel] readwriteUuid usage on metadata creation

Hi list,

I'm dealing with a plugged schema which has a non-standard metadata identifier;
it means it's not an UUID, but has to be somehow "processed".
As already suggested by Francois, I'm using the update-fixed-info xsl to
perform this task, in a schema which defines
<readwriteUuid>true</readwriteUuid> in its schema-ident.

It works nicely when updating a metadata, but, when the metadata is first
created, the UUID which is reported to the persistence logic is still the
automatic generated UUID.

It means that, just after creating the new metadata, inside the persisted XML
metadata I get the correct fileIdentifier generated by the update-fixed-info, and
in the data.uuid DB field I have the new UUID generated by GN, which is wrong.
The data.uuid value is properly set only after the first save/update.

I guess that in DataManager.createMetadata(...), after calling the
updateFixedInfo(...), something similar to these lines

        if (schemaMan.getSchema(schema).isReadwriteUUID()) {
            uuid = extractUUID(schema, md);
        }

(copied from updateMetadata()) should be added.

Do you see any drawback in this fix?

   Ciao,
   Emanuele

--

== *GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014* ==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Hi Emanuele,

I personnaly don’t see any drawback to this.
IMO, if the uuid has been changed by the updateFixedInfo, then the uuid DB field should be updated as well.

This should also be the case on a metadata insert.

I’m having same kind of issue on a metadata insert.

  1. Your fix should be applied too
  2. There is a boolean in the insert method to decide if we call updateFixedInfo method or not.
    https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/java/org/fao/geonet/kernel/DataManager.java#L1385

I don’t understand why this boolean is set to false in the case of an import :
https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/java/org/fao/geonet/kernel/mef/Importer.java#L531

Any reason why this is false ?
Should be true because in the case where the uuid is modified, this causes some issues.

···

On Fri, Dec 20, 2013 at 3:42 PM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi list,

I’m dealing with a plugged schema which has a non-standard metadata identifier;
it means it’s not an UUID, but has to be somehow “processed”.
As already suggested by Francois, I’m using the update-fixed-info xsl to
perform this task, in a schema which defines
true in its schema-ident.

It works nicely when updating a metadata, but, when the metadata is first
created, the UUID which is reported to the persistence logic is still the
automatic generated UUID.

It means that, just after creating the new metadata, inside the persisted XML
metadata I get the correct fileIdentifier generated by the update-fixed-info, and
in the data.uuid DB field I have the new UUID generated by GN, which is wrong.
The data.uuid value is properly set only after the first save/update.

I guess that in DataManager.createMetadata(…), after calling the
updateFixedInfo(…), something similar to these lines

if (schemaMan.getSchema(schema).isReadwriteUUID()) {
uuid = extractUUID(schema, md);
}

(copied from updateMetadata()) should be added.

Do you see any drawback in this fix?

Ciao,
Emanuele

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



Rapidly troubleshoot problems before they affect your business. Most IT
organizations don’t have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk


GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork


Florent Gravin
Camptocamp - Chambéry
0479444492

Hi,

···

2014/1/2 Florent Gravin <florent.gravin@anonymised.com>

Hi Emanuele,

I personnaly don’t see any drawback to this.
IMO, if the uuid has been changed by the updateFixedInfo, then the uuid DB field should be updated as well.

This should also be the case on a metadata insert.

I’m having same kind of issue on a metadata insert.

  1. Your fix should be applied too
  2. There is a boolean in the insert method to decide if we call updateFixedInfo method or not.
    https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/java/org/fao/geonet/kernel/DataManager.java#L1385

I don’t understand why this boolean is set to false in the case of an import :
https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/java/org/fao/geonet/kernel/mef/Importer.java#L531

Any reason why this is false ?

I think mainly because MEF is supposed to restore a catalog backup as it was (no changes on datestamp, nor uuid, …).

Should be true because in the case where the uuid is modified, this causes some issues.

But in case a profile allows uuid modification, it sounds relevant to apply the updateFixedInfo or at least a step which takes care of uuid update/synch. I see 3 options:

  1. add a parameter in the import page to apply updateFixedInfo
  2. apply updateFixedInfo for profile with read/write uuid
  3. create a step to update/synch uuid only (to not alter dateStamp, …)

Anyway, if a record in a specific profile allowing read/write uuid, the uuid should remain the same after updateFixedInfo in most of (all) the cases. It may only change if a) the uuid is computed by a rule which change (should not happen as far as the profile is specified) or b) the uuid is based on some other field in the metadata record and the uuid is not in synch with those fields.

Cheers.

Francois


Rapidly troubleshoot problems before they affect your business. Most IT
organizations don’t have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk


GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

On Fri, Dec 20, 2013 at 3:42 PM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi list,

I’m dealing with a plugged schema which has a non-standard metadata identifier;
it means it’s not an UUID, but has to be somehow “processed”.
As already suggested by Francois, I’m using the update-fixed-info xsl to
perform this task, in a schema which defines
true in its schema-ident.

It works nicely when updating a metadata, but, when the metadata is first
created, the UUID which is reported to the persistence logic is still the
automatic generated UUID.

It means that, just after creating the new metadata, inside the persisted XML
metadata I get the correct fileIdentifier generated by the update-fixed-info, and
in the data.uuid DB field I have the new UUID generated by GN, which is wrong.
The data.uuid value is properly set only after the first save/update.

I guess that in DataManager.createMetadata(…), after calling the
updateFixedInfo(…), something similar to these lines

if (schemaMan.getSchema(schema).isReadwriteUUID()) {
uuid = extractUUID(schema, md);
}

(copied from updateMetadata()) should be added.

Do you see any drawback in this fix?

Ciao,
Emanuele

== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



Rapidly troubleshoot problems before they affect your business. Most IT
organizations don’t have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk


GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork


Florent Gravin
Camptocamp - Chambéry
0479444492

Hi Florent and Francois,

Alle 08:39:44 di Friday 3 January 2014, Francois Prunayre ha scritto:

Hi,

2014/1/2 Florent Gravin <florent.gravin@anonymised.com>

> Hi Emanuele,
>
> I personnaly don't see any drawback to this.
> IMO, if the uuid has been changed by the updateFixedInfo, then the uuid
> DB field should be updated as well.
>
> This should also be the case on a metadata insert.
>
> I'm having same kind of issue on a metadata insert.
> 1. Your fix should be applied too
> 2. There is a boolean in the insert method to decide if we call
> updateFixedInfo method or not.
>
> https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/
> java/org/fao/geonet/kernel/DataManager.java#L1385
>
> I don't understand why this boolean is set to false in the case of an
> import :
>
> https://github.com/geonetwork/core-geonetwork/blob/develop/core/src/main/
> java/org/fao/geonet/kernel/mef/Importer.java#L531
>
> Any reason why this is false ?

I think mainly because MEF is supposed to restore a catalog backup as it
was (no changes on datestamp, nor uuid, ...).

> Should be true because in the case where the uuid is modified, this
> causes some issues.

But in case a profile allows uuid modification, it sounds relevant to apply
the updateFixedInfo or at least a step which takes care of uuid
update/synch. I see 3 options:
1) add a parameter in the import page to apply updateFixedInfo
2) apply updateFixedInfo for profile with read/write uuid
3) create a step to update/synch uuid only (to not alter dateStamp, ...)

Please note that you are talking about 2 different issues:
- when the updateFixedInfo should be called
- when/if the UUID on DB should be updated.

In my specific case, the updateFixedInfo is properly called on metadata
creation.
What is not done, is the porting of the new generated fileIdentifier as the
metadata uuid in the DB, thus breaking the alignment between them.
(As reported in a previous email, the alignment is corrected as soon as the
metadata is updated.)
My proposed fix would only set the modified UUID if the profile has a read/write
uuid.

Anyway, if a record in a specific profile allowing read/write uuid, the
uuid should remain the same after updateFixedInfo in most of (all) the
cases. It may only change if a) the uuid is computed by a rule which change
(should not happen as far as the profile is specified) or b) the uuid is
based on some other field in the metadata record and the uuid is not in
synch with those fields.

In the profile I'm working on, the requirements are about inserting a fixed
string as a prefix in the UUID. Of course this is needed only once when
creating the metadata record.
In this case the UUID should not be replaced when importing MEF.

   Cheers,
   Emanuele

> On Fri, Dec 20, 2013 at 3:42 PM, Emanuele Tajariol <etj@anonymised.com

solutions.it>wrote:

>> Hi list,
>>
>> I'm dealing with a plugged schema which has a non-standard metadata
>> identifier;
>> it means it's not an UUID, but has to be somehow "processed".
>> As already suggested by Francois, I'm using the update-fixed-info xsl to
>> perform this task, in a schema which defines
>> <readwriteUuid>true</readwriteUuid> in its schema-ident.
>>
>> It works nicely when updating a metadata, but, when the metadata is
>> first created, the UUID which is reported to the persistence logic is
>> still the automatic generated UUID.
>>
>> It means that, just after creating the new metadata, inside the
>> persisted XML
>> metadata I get the correct fileIdentifier generated by the
>> update-fixed-info, and
>> in the data.uuid DB field I have the new UUID generated by GN, which is
>> wrong.
>> The data.uuid value is properly set only after the first save/update.
>>
>> I guess that in DataManager.createMetadata(...), after calling the
>> updateFixedInfo(...), something similar to these lines
>>
>> if (schemaMan.getSchema(schema).isReadwriteUUID()) {
>>
>> uuid = extractUUID(schema, md);
>>
>> }
>>
>> (copied from updateMetadata()) should be added.
>>
>> Do you see any drawback in this fix?
>>
>> Ciao,
>> Emanuele
>>

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------