Hi Marc, >>> An idea here could be to re-package the .odb using the database part as >>> a single item with compression -0, but I think zip doesn't support this. >> It does. The meta information in all of OOo's document is uncompressed, >> for quicker access. However, still the complete package has to be >> written when you only change a single byte. > > At least one possibility. If a scheme of temporarily writing to a random > access file and adding the (closed) ra-file to the zip when closing > the .odb would be introduced.
Something like this is already in place. HSQL's data files (which you find inside the "database" folder of an .odb) are RA files, since they're HSQL's normal backend format, which of course is RA for non-trivial data sizes. Also, every file in the ZIP package is extracted as one temporary file. So effectively, the normal work already happens on RA files. However, there still is the problem of pulled plugs (or, since rumors say this sometimes happens, of OOo crashing): You'll lose all your data since the last committing of the temporary files to the .odb. So, if we commit too seldom, you lose "too much" data (don't shoot me, I know that every single byte is "too much" in this context). If we commit too often, your work flow suffers, since every commit takes the more time the greater the DB is. Which, hmm, perhaps leads back to your idea of doing the committing in the background ... > That's an interesting thought, if you say the ODF file only will contain > the metadata and the real data is stored in an (not completely, see > above) external high performance container file. Well, for all DBs except embedded HSQL this is the case - e.g., if you connect to an MySQL or PostgreSQL server :) > Since it is my personal pet for storing hirarchical measurement data I > could imagine HDF5 as a portential candidate. > ... Interesting. I'm not sure what our OASIS guys would say if I suggest using a file format which, though open, is under the control of a single company, but I will read a little. >>> <shouting "Jehova mode> >>> Other databases using binary files having a jdbc driver may fit this >>> requirement, too. Firebird would be a candidate. >>> </shouting "Jehova mode> >> Sure. Do you volunteer to write the driver/integration for FB? :) > > No, definitly not. That's why I tagged this remark with some sort of > "humor sign". ;) Oh. Should I have said "Ist hier etwa Weibsvolk anwesend?" to show I understood it? :) > Although I'd appreciate having drivers for Firebird, DB2 and other would > be nice, this is far beyond the scope of my time. How much work would it > be to write a driver? Depends. Usually, if you have a good API to connect to, this shouldn't be too much work (a few man weeks, I'd say). However, dedicated drivers exist because generic (ODBC/JDBC/ADO) drivers do not care for all specialities of the specific DB. Depending on how many of those you want to address, it can take arbitrarily longer. Look, Joerg Budischewski is enhancing his PosgreSQL driver for *years* now ;) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
