CMDBuild Forum

Exporting CSV fails

Old Versions
#1

I have several classes. Some of those can be exported to CSV file, but few fails. I'm getting Tomcat 500 error message without any clue what causes it.

Export fails immediately without asking file name etc.

I'm using CMDBuild version 2.1.8

I found this from Log:

DEBUG 2015-12-17 11:11:11 [jsonrpc ]     parameter "className": AppList
DEBUG 2015-12-17 11:11:11 [jsonrpc ]     parameter "separator": ;
DEBUG 2015-12-17 11:11:11 [jsonrpc ] Uncaught exception calling method class org.cmdbuild.servlets.json.management.ExportCSV.export
java.lang.RuntimeException
        at org.cmdbuild.servlets.json.management.export.csv.CsvExporter.export(CsvExporter.java:35)
        at org.cmdbuild.logic.data.access.DefaultDataAccessLogic.exportClassAsCsvFile(DefaultDataAccessLogic.java:1040)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:622)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:196)
        at com.sun.proxy.$Proxy62.exportClassAsCsvFile(Unknown Source)
        at org.cmdbuild.servlets.json.management.ExportCSV.export(ExportCSV.java:24)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:622)
        at org.cmdbuild.servlets.JSONDispatcher.dispatch(JSONDispatcher.java:97)
        at org.cmdbuild.servlets.JSONDispatcher.doPost(JSONDispatcher.java:57)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.cmdbuild.filters.AuthFilter.doFilter(AuthFilter.java:144)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.cmdbuild.filters.PatchManagerFilter.doFilter(PatchManagerFilter.java:33)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.cmdbuild.filters.ConfCheckFilter.doFilter(ConfCheckFilter.java:31)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.cmdbuild.filters.TranslationFilter.doFilter(TranslationFilter.java:39)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
        at java.lang.Thread.run(Thread.java:701)

#2
 
Does the problem occur also with the latest CMDBuild versions (2.3.4) ?
CMDBuild Team
#3

I haven't tried it yet, because there has not been any new features we need. According to release notes there has not been any bug fixes to ExportCSV.

If we decide to upgrade, can I update 2.1.8 directly to 2.3.4?

#4

This is not a known issue.
But after your version we have changed the CMDBuild DAO (Data Access Object) and it may be that your problem has been solved.
We suggest that you do a migration test on a non-production instance to ensure that the update fix the error and has no side effects.
We confirm that you can upgrade directly from version 2.1.8 to the latest version.
CMDBuild Team

#5

Before upgrading to latest version I did some more testing...
One example of classes that fail in export is:

class:
* Test1

attributes:
* Code - String 100
* Description - String 250
* Value - Text (Plain text)

I deleted the contents of class:
* TRUNCATE "Test1" CASCADE;
* TRUNCATE "Test1_history" CASCADE;

After that I logged out and back in, but exporting empty class still fails.

I removed class, logged out and back in, recreated similar table, but export still fails.

I Imported CSV successfully, but after that export still fails.

I created similar class with name Test2. Export and import of that class is ok. However there is no option for changing name of class so this was not workaround for my problem.

So... Is there something more left in database after truncating Test1 and Test1_history? Do you have any tweaks in mind that could be tested before upgrading latest version? I guess that it will take month or two before we can have new version in production and I need to get those exports before that...

#6

It is not a correct operation to perform a “truncate” on the database.
This creates inconsistencies that make the data unusable CMDBuild.
I suggest you make “not active” the class in which you deleted the data and create another class with a different name.
CMDBuild Team

#7

Yeah, I know it is naughty thing to mess with database...

It is not so simple to change the name of a class, because we have lots of code relferring to specific class name(s). I wish it would be so easy.

Is there any (naughty) way to get rid of a class so that there would not be any trace of it?

#8

I’m sorry, but there is no automatic procedure to do this.
It is necessary to analyze the dependencies of that class, prepare a custom sql script and run it in a controlled manner, but this takes time.
CMDBuild Team

#9

This Test1 is independent class. There are no references to this class from other classes. So I have not made relations between this class and others, but there may be system tables that need to be fixed as well - or???

Can you point out where to find those relations...