> Am 30.06.2024 um 05:41 schrieb [email protected]: > > > Thanks for this. Sounds really cool. > > One thing I keep wondering about is the comment at ESUG that the serializer > had to be rewritten from the ground up (no pun intended ha ha) because Fuel > is neither flexible nor fast. Fuel has become such an integral part of the > ecosystem that it seems a shame it couldn’t help here. Was there any thought > about modifying Fuel to make it more flexible and/or fast? > The first version was using fuel because that was my initial plan not to waste time on developing something that is already there. I‘m not sure I can recall precisely but it was really hard to get it doing what I want
hooks / extension points We want to tell an object when it just has been materialized so it can take something like post-initialization and such. It was not easy to add that to fuel class management/lookup Soil has class versions (how could it work without?) So whenever you materialize something you need to be able to manage the description of a class and inject properly so that you can materialize and migrate old versions. Migrations are the overall weak point of fuel and soil needs it badly general design Fuel does analysis steps and then writes a graph as a whole trying to optimize storage space and read performance. At least that‘s what I think were the rationales for doing that pickle format and class storage. But it does all of this in one stroke making fuel a good tool when you are only interested in the resulting blob. In soil we want to have something like a streaming writer with a simple approach. Therefor the serializer is similar to the Omnibase one which simple, good and fast. I did not thoroughly test performance but the benchmarks I‘ve did showed that fuel is not even faster. This might be wrong development The later changes on fuel are IMHO make fuel even less flexible and tend to be over-engineered (Max, that is my personal opinion and should not taken as a general statement) me It was an insane idea to start doing a database and expect to succeed with it in a short time frame. But I was forced to do it because I was migrating ApptiveGrid to OmniBase just to learn at a very late time that it is not open source because someone stupid just put intentionally an MIT license onto it after copying the source code to github. So I was not tempted to have a lot of patience with something like fuel when it starts to block my way I hope this is a proper answer to that very good question Norbert > Thanks again, > > Sean
