Hi Thomas, Thank you for the update. I would like to help the project implement LOBs with MVTableEngine. I may need to get more familiar with the project's source before I can add something to it.
As I am looking at the source, I see that the current documentation about the LOB storage is somewhat out of sync with the actual code. I have just filed an issue about that at http://code.google.com/p/h2database/issues/detail?id=459&can=6 . It is not yet clear to me why a database using `MVTableEngine` as the default engine fails to store LOBs. The current version of H2 splits larger LOBs into chunks and stores them in a hidden table within the same database. - Why isn't that table saved in MVStore like any other table? If it was, no special provisions for storing LOBs might be necessary. But maybe that's not the goal. You mentioned the `org.h2.mvstore.StreamStore` class as the facility that can store LOBs for MV tables. Let's assume that we want to implement a bridge between `org.h2.store.LobStorage` and `StreamStore` or a drop-in replacement for `LobStorage`. Then we should decide how to store LOBs for multiple tables in a database that may use different table engines. Currently, `LobStorage` creates hidden tables `LOBS`, `LOB_DATA`, and `LOB_MAP` using the default table engine for the database. The choices I see are: 1. Use the default engine of a database to store all its LOBs. The bridge will be used if `MVTableEngine` is the database's default, otherwise `LobStorage` will just work as it does now. The bridge class could also replace `LobStorage` for such databases. 2. Require each TableEngine implementation to provide a facility that would store LOBs for respective tables. Such facilities shall maintain their own hidden tables or other mechanisms to manage their LOBs. References to LOBs within a table will be resolved using that table's engine. 3. Allow TableEngine implementations to provide facilities for LOB storage as an option. Engines that do not implement their own LOB storage will have respective tables fall back to the current `LobStorage` implementation with database-wide hidden tables containing the LOBs' chunks. Please let me know your opinion about which way to proceed with the implementation. Maybe you can suggest other options besides these. Best regards, Stan. On Apr 20, 1:57 pm, Thomas Mueller <thomas.tom.muel...@gmail.com> wrote: > Hi, > > > Has anyone tried storing a BLOB in a database that uses MVTableEngine? > > I didn't test it yet. Please note the MVTableEngine is very much work in > progress. There are still quite many missing features, and it will take a > while until it's ready. I'm not sure if it makes sense yet to test it, > unless you want to help implementing it. But anyway thanks a lot for the > test case! I will write a test case based on your code. So you don't need > to file a bug or so. > > At this stage I'm implementing the basic transactional features (class > TransactionStore). > My original implementation of that class was much too slow, and the current > implementation also isn't good enough yet, for example because it generates > many short-lived objects. This will need to be fixed first. Then, there are > still quite many missing features. The blob / clob storage might be based > on org.h2.mvstore.StreamStore (not sure yet). > > Regards, > Thomas > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
