Am 03.09.2024 um 03:04 schrieb sean@clipperadams.com:

Exciting news!
Two questions:
How is the stability? I am finally outgrowing SimplePersistence, but some of my systems are too critical to risk beta testing��

I think the only way finding out is to try. In ApptiveGrid we have 5000 instances and it is in production over one year. I wouldn't say there weren't problems in that time. But for me it is quite some time since I've found a conceptual problem that caused errors. This doesn't mean that it works for you and you won't bump into something the first time you use it. Stability is use case dependent.

I remember hearing (or reading?) that Fuel wasn��t used underneath because it wasn��t flexible or fast enough. Is that correct? If so, is there anywhere I can read about this analysis? Or would you touch on it here? It seemed like a lot of community resources were invested in Fuel so it��s disappointing that a rewrite felt necessary and I��m wondering if any of the lessons learned in Soil could help Fuel.

The new implementation is only questionable from a bird's eye view. Meaning when you put them under the coarse grained category serializers. That is not appropriate for many things because the way you use it is important.

Fuel is a whole graph serializer. Meaning you give it one object and then it produces an efficient serialized blob out of it. There are not many interception points.
Soil supports graph partitioning, meaning that your graph will be sliced into smaller parts in order to have efficient control over the amount of data needs to be read/written. Adding that to fuel was hard and in the end did not give enough control to tweak
Fuel has its own way of managing class names which needs pre-processing which is not suited if you want to use streaming objects to disk
Fuel only supports management of class names because it assumes them to be there in the image. Soil stores class descriptions in the database. Adding that to Fuel wouldn't be rather difficult.
Soil has class versions because as it is a database you can store data in one shape and then change the code. So we need proper migration support which in Fuel is only doable with a central registry and an external version managment
Soil separates content and structure completely, meaning sub-graphs are stored together but everything referencing and addressing is done on the database level, meaning you can deal with the structure without having the code at hand etc.
Soil uses byte type codes for special types to map it efficiently as type-length-value format onto disk. Fuel has no support for how you store objects on disk.
...

Hope this gives a bit more insight than last time. I did not "just wanted to do my own", I considered using Fuel but it didn't work. So as usual there is no one-fits-all solution. And this is a good example.

Norbert