Hi,
In our unit-tests we do the following a lot when we verify that
writing/reading the data keeps things at their expected state/place.
This writes the spreadsheet to a byte[] and then reads it back in as
new Workbook.
ByteArrayOutputStream baos = new ByteArrayOutputStream(4096);
original.write(baos);
ByteArrayInputStream bais = new
ByteArrayInputStream(baos.toByteArray());
return new HSSFWorkbook(bais);
You can probably do something similar here to avoid the I/O overhead,
i.e. keep the byte[] resulting from baos.toByteArray() and create new
Workbooks off of that. Unless the workbook is large or complex it
should not take too long to build the Workbook from the byte[]...
Dominik.
On Tue, Jan 20, 2015 at 10:38 PM, Blake Watson <[email protected]> wrote:
>
> Hello--
>
>
> I'm still looking for a way to copy a spreadsheet in memory and have some
> assurance that it's a fully functioning, legit copy.
>
> My situation is that I pull up a spreadsheet in a web server, then put up a
> browser front end that allows users to populate that spreadsheet. This, of
> course, results in a changed spreadsheet.
>
> The problem:
>
> 1. While each user populates all the same cells every time, and therefore
> theoretically is isolated from other users' changes, in practice a single
> user might cause a chain of events that breaks the spreadsheet for
> everyone, due to the squishy, stateful nature of things. This happens when
> I load the spreadsheet once and keep it in memory.
>
> 2. I've tried to avoid problem 1 by reloading the file from disk every
> time. This creates a drag on the user interface, which is live updating as
> the user types.
>
> Now, I can roll back to a non-live thing and force the user to request
> changes, but I'd prefer not to. The live interface is cool because it shows
> the users the effect of what they're typing on the output, as they're
> typing.
>
> I would just create a new workbook object and clone the sheets into it, but
> I'm not sure that won't leave some important settings out. Maybe there's
> nothing going on behind the scenes but I can't help but think there's a
> reason there is no "cloneWorkbook" method.
>
> I'll probably next try keeping the file in memory, in case the disk access
> time is significant. If that doesn't resolve the issue, I may then try
> setting up a process to keep a cache of parsed Workbooks available. But
> that seems...needlessly elaborate.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
