You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@poi.apache.org by Blake Watson <bl...@pnmac.com> on 2015/01/20 22:38:02 UTC
Re: Clone a workbook?
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.
Re: Clone a workbook?
Posted by Blake Watson <bl...@pnmac.com>.
Thanks, Dominic.
That will probably work for me. I think the parsing only =seems= to take a
long time sometimes, but it's just the I/O.
On Wed, Jan 21, 2015 at 12:16 PM, Dominik Stadler <do...@gmx.at>
wrote:
> 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 <bl...@pnmac.com>
> 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: user-unsubscribe@poi.apache.org
> For additional commands, e-mail: user-help@poi.apache.org
>
>
--
*Blake Watson*
*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.watson@pnmac.com <me...@pnmac.com>
www.PennyMacUSA.com <http://www.pennymacusa.com/>
Re: Clone a workbook?
Posted by Dominik Stadler <do...@gmx.at>.
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 <bl...@pnmac.com> 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: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org