Community
Participate
Working Groups
When running large reports in run then render mode, the .rptdocument file can be very large for large reports. At the same time, these large, long running reports are just the type of thing that a user might want to keep for a long time. I propose that we create a new report document extension named ".rptdoczip". When a user uses the RunTask to run a report the task would support the new extension name. This content of this extension would be compressed using the standard java compression techniques (java.util.zip). IRunTask task = reportEngine.createRunTask(design); task.run("output/report_engine/customers.rptdoczip"); The actual implementation would be done as an extension of the ArchiveWriter class which would be named ZipFileArchiveWriter. On the other side of the equation, we would have a ZipFileArchiveReader. The ZipFileArchiveReader would be used by all of the classes that open rptdocuments. - Render Task - Data Extraction Task - Parameter Details Task These tasks would be modified to recognize the .rptdoczip file extension and to use the ZipFileArchiveReader class when appropriate.
Wei, Can this enhancement be done via an extension point to ArchiveWriter? Sounds like we need to add code in engine to check the file extension to decide if an compress extension is called. Also, if we support different compress alg and/or different version of the java compression class, do we need to have a mapping between the file suffix and the compression extension plugin? The plugin will need to advertise the suffix that it can handle. If we need to add a new extension point, it would be too late to add in 2.3.0. Maybe consider 2.3.1?
It is hard to support ZIP in the archive interface as BIRT needs access those streams randomly both in read and write. If we need support the compressed report document, a possible solution maybe: 1. compress the archive when the user close the archive file for writing. 2. flat the zip file to an temp file when user open the archive file. This solution has heavy IO loads especially for large archive file. suggest consider it in future release.
