> I guess in most cases people will want to use regular Java objects on the 
> client side (String, Integer, Long,...) - in that case there is no 
> (efficient) way I know to avoid copying the data first to a ByteBuffer.
>

Of course when you work with conventional file system it is more effective 
to write data to some buffer in memory and then flush it to FS instead of 
writing byte after byte to file directly but in case of in-memory file 
system situation is opposite.
 

> I guess what you mean is that if an application uses Map<..., ByteBuffer> 
> or Map<..., byte[]>, the MVStore should avoid copying the data. It could be 
> done, but I'm not sure if this is such an important use case to justify the 
> added complexity. It might make sense if you store relatively large 
> binaries, but I'm not sure. In such cases, it might make sense to store the 
> binaries outside of the database in their own files, just because freeing 
> up disk space would be a lot simpler that way. The MVStore is really more 
> about database records and not so much about really large binaries.
>

It is an interesting use case too but for real I'm talking about filesystem 
abstraction which is independent of key and value data types. Basically I 
suggest in DataType use some interface instead of ByteBuffer (something 
similar to DataOutput). And get an instance of that interface from File 
abstraction like file.getOutput(long pos, long size). That way file system 
implementation can decide itself how to do the things internally - may be 
using ByteBuffer or byte[] or write data directly to the location. It does 
not seem to introduce any complication or performance penalty.

Sergi

-- 
You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/h2-database/-/ZSmSomGx_AkJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/h2-database?hl=en.

Reply via email to