Well, you need to study the sources further as such capabilites already exist. Depending on table type, we store the data in different forms. One of these forms (for CACHED tables) has similarities to the paged file storage used by other products.
In short, you can build and access a database with up to 8GB binary data using only 64MB or less memory allocation. Fred ----- Original Message ----- From: "th643138" <[EMAIL PROTECTED]> To: <[email protected]> Sent: 10 November 2005 12:11 Subject: [Hsqldb-developers] architecture of the persistence package...? hi, i´m new to this mailing list and the hsql-project... during the analysis of the source-code to get an understanding how the things interact and work together, it struck me that the way to make databases persistent is to write all rows of an table into one large binary file using random acces methods (file pointers, seek,...) so is the resulting structure of the file (rows appended everytime) one large serialized block, containing all table information... ->did i understood that correct? doing that this way causing some questions in my mind... how do you store variable length character fields? did you allocate the maximum field size or take you advantage of real variable sized records? (eigther embedded fields or attached variable length fields at the end of the records fixed size fields) the question is, your persistence-strategy (as described above) gets realy into trouble if you enlarge the content of variable sized record-fields... same occours if someone want to alter an existing table and wanna insert an new row... the result should be to restructure the datafile containing the table data, because there is no available space between the serialized records, according record-acces with an real file-offset... ->doing that this way may acceptable on small database files... but on your feature list you promote to support very large databases up to 8 gig... (maybe with the capability of internal structures, but not really in practise... pour performance...) an better solution (specially if you wana use the engine as an server) should be an paged file as described in most database-architecture books so my question, is anyone working on such an persistence-layer? if not, i´m interested in try to do it... as result that could easily support different page-insert strategies (update in place or allocate a new pages) furthermore that would support great revised physical logging ciao thomas ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ hsqldb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ hsqldb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
