Trivial doc/interface fix
2006-03-13
Jesus CeaRe: Trivial doc/interface fix
2006-03-13
Jesus Cea2006-03-13
David BingerA new backend storage (Re: [Durus-users] Re: Trivial doc/interface
fix)
2006-03-13
Jesus CeaRe: A new backend storage (Re: [Durus-users] Re: Trivial
doc/interface fix)
2006-03-13
Peter Wilkinson (2 parts)Re: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface
fix)
2006-03-14
Peter FeinRe: A new backend storage (Re: [Durus-users] Re:
Trivial doc/interface fix)
2006-03-14
David BingerRe: A new backend storage (Re: [Durus-users] Re: Trivial
doc/interface fix)
2006-03-14
David BingerRe: A new backend storage (Re: [Durus-users] Re: Trivial doc/interface
fix)
2006-03-14
Jesus Cea2006-03-13
Peter Wilkinson (2 parts)2006-03-21
Jesus CeaRe: Trivial doc/interface fix
Peter Wilkinson
On 14/03/2006, at 8:23 AM, David Binger wrote: > Okay. I'll add those two to Storage. > > It sounds like you are implementing a Storage. > That's good. Interestingly just this past weekend I spent a couple of hours being curious about how storage backends work and in the process put together a SQLite backend. Rather perverse in some ways but has some interesting benefits on startup speed and memory consumption as no index needs to be built in memory, start up on a 3million entry database is instant. I'm not sure that what I'm doing is much more than a exercise in getting a better understanding the internals of Durus, we are looking to move all our application development to Durus to have been poking around for a while. I was very pleasantly surprised by how easy it is to write a storage engine, though one thing that did make the code a little more complicated and less able to be optimized was the storage engine being handed already packed and encoded values for oid and record to store. If the actual oid and instance of the record was passed down some interesting optimizations could be done. All up I can say such a small and effective code base is a joy to experiment with. Peter W.