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 <[email protected]> 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 <[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] > > -- *Blake Watson* *PNMAC* Application Development Manager 5898 Condor Drive Moorpark, CA 93021 (805) 330.4911 x7742 [email protected] <[email protected]> www.PennyMacUSA.com <http://www.pennymacusa.com/>
