[GeoNetwork-devel] Metadata insert via MEF2 file does not seem to be handling errors.

I was just looking at the code for uploading MEF files and I don't see how
anything is added to the error list.

When I successfully upload 5 records within an mef2 file I get the following
report.

However if I remove 4 of the records and try to import them again I was
expecting to get 1 error due to duplicates and the other 4 should be
reinserted - but instead I get the following

And if I attempt to load invalid data along with good data - again I don't
get a partial load with errors as I would have expected I get the following
error.

I would have expected the load to catch any exceptions after the load of
each record - if it caught an error it would increase the error count
otherwise it would increase the successful count. But when I look in the
code I don't see any such logic.
So I'm wondering if the report should be change to remove the "0 errors"
since I'm not sure how it would ever be anything else but 0? Or should the
mef2 load process be updated to keep track of the errors?

Maybe I'm misunderstanding this # errors in the report?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.

Hi,

It makes sense, we could have a general report that tells user what happened for each metadata in the MEF file.
However, we could also want the behavior that all metadatas are imported or none.

Anyway, the report should be improved.
Are you working on that ?

I’m working on a new metadata import panel (just the same as before but with extjs component) : https://github.com/fgravin/core-geonetwork/tree/InsertMDWin

It’s almost finished but still need to manage MEF import response, display errors, or behave in case of success.
But the MEF import seems to be broken in develop branch.

Here is what i do :

  • i select 3 metadatas, i export them as ZIP
  • i go into Import Metadata admin page
  • i chose MEF, my zip file then OK

then i have a FileNotFoundException : /home/fgravin/dev/geonetwork/web/src/main/webapp/./data/tmp/unzipping/e583ebb9-402e-4d2f-bc7a-18b93d474298/metadata/metadata.xml (No such file or directory)

The extraction in a temp dir fails.

Could you make it work on your side ?
I created an issue https://github.com/geonetwork/core-geonetwork/issues/177 i will check this if no one it working on it.

Cheers,

···

On Wed, Jul 17, 2013 at 4:50 PM, ianwallen <ianwallen@anonymised.com> wrote:

I was just looking at the code for uploading MEF files and I don’t see how
anything is added to the error list.

When I successfully upload 5 records within an mef2 file I get the following
report.

However if I remove 4 of the records and try to import them again I was
expecting to get 1 error due to duplicates and the other 4 should be
reinserted - but instead I get the following

And if I attempt to load invalid data along with good data - again I don’t
get a partial load with errors as I would have expected I get the following
error.

I would have expected the load to catch any exceptions after the load of
each record - if it caught an error it would increase the error count
otherwise it would increase the successful count. But when I look in the
code I don’t see any such logic.
So I’m wondering if the report should be change to remove the “0 errors”
since I’m not sure how it would ever be anything else but 0? Or should the
mef2 load process be updated to keep track of the errors?

Maybe I’m misunderstanding this # errors in the report?


View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.


See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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

Florent,

No, I'm not working on the report.

Regarding the import (file not found) - I have performed multiple imports in
the last couple weeks using 2.10.0 and did not have any issues. So I'm not
able to reproduce the issue. Have you tried unzipping the zip file manually
to see if the metadata.xml file exists in the zip file? What version did you
test this on?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091p5068918.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.

Hi,

I’m testing the latest develop branch.
But this issue is there for me since a while.

I tried to extract manually yes but the boring thing is that the temp extracted folder is removed each time.

···

On Fri, Jul 26, 2013 at 12:58 PM, ianwallen <ianwallen@anonymised.com> wrote:

Florent,

No, I’m not working on the report.

Regarding the import (file not found) - I have performed multiple imports in
the last couple weeks using 2.10.0 and did not have any issues. So I’m not
able to reproduce the issue. Have you tried unzipping the zip file manually
to see if the metadata.xml file exists in the zip file? What version did you
test this on?


View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091p5068918.html

Sent from the GeoNetwork developer mailing list archive at Nabble.com.


See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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

Florent

By extracting I meant to unzip the file after you have did the export so
that you can see what you are uploading to the server. The metadata.xml file
should exists in that zip file otherwise it sounds like the issue may be
with the export and not the import.

Did you try to test exporting/importing the sample iso19139 records? This is
what I did my testing without any issues. Just saying this because the issue
may be related to the type of metadata records.

If I happen to find time, I will try to test the trunk to see if I can
reproduce the error.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091p5069008.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.

Hi, thanks for your reply.

I succeeded bypassing this bug to make my tests.
The bug is not in the export, the ZIP file is OK.

But it is in the unzip method, that just fails to extract all files.
It may be related to the type of metadata records you are right.

Will see if we have time to check this a bit deeper.

Thanks for your help

···

On Fri, Jul 26, 2013 at 6:09 PM, ianwallen <ianwallen@anonymised.com> wrote:

Florent

By extracting I meant to unzip the file after you have did the export so
that you can see what you are uploading to the server. The metadata.xml file
should exists in that zip file otherwise it sounds like the issue may be
with the export and not the import.

Did you try to test exporting/importing the sample iso19139 records? This is
what I did my testing without any issues. Just saying this because the issue
may be related to the type of metadata records.

If I happen to find time, I will try to test the trunk to see if I can
reproduce the error.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091p5069008.html

Sent from the GeoNetwork developer mailing list archive at Nabble.com.


See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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

MEF Import had obviously a bug while unzipping files, it has been fixed.

see : https://github.com/geonetwork/core-geonetwork/issues/177

···

On Tue, Jul 30, 2013 at 12:00 PM, Florent Gravin <florent.gravin@anonymised.com> wrote:

Hi, thanks for your reply.

I succeeded bypassing this bug to make my tests.
The bug is not in the export, the ZIP file is OK.

But it is in the unzip method, that just fails to extract all files.
It may be related to the type of metadata records you are right.

Will see if we have time to check this a bit deeper.

Thanks for your help


Florent Gravin
Camptocamp - Chambéry
0479444492

On Fri, Jul 26, 2013 at 6:09 PM, ianwallen <ianwallen@anonymised.com> wrote:

Florent

By extracting I meant to unzip the file after you have did the export so
that you can see what you are uploading to the server. The metadata.xml file
should exists in that zip file otherwise it sounds like the issue may be
with the export and not the import.

Did you try to test exporting/importing the sample iso19139 records? This is
what I did my testing without any issues. Just saying this because the issue
may be related to the type of metadata records.

If I happen to find time, I will try to test the trunk to see if I can
reproduce the error.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Metadata-insert-via-MEF2-file-does-not-seem-to-be-handling-errors-tp5067091p5069008.html

Sent from the GeoNetwork developer mailing list archive at Nabble.com.


See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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