Sounds good. Using Fuel to serialize/deserialize should be fine, but I had unhappy experience with early versions where a newer Fuel version could not read content written by earlier Fuel versions.
In my mind, a disk-based B-tree is the fundamental data structure for any database (e.g. GemStone, Omnibase, Relational DBs all have it), but I don’t see it mentioned so far. Everything else about a "database" is optional, IMHO. For example, a query language is not needed at all, if the data items are equivalent to objects running in a Smalltalk VM - the query language is Smalltalk itself. It “just” has to mesh well with the indexing. Another feature is MVCC. How much concurrency is needed, and how it is implemented, is an implementation choice. I’d mentioned LMDB on Discord. It has single writer, many readers. Choosing to have multiple simultaneous writers has a cost. When there is one or more big machines, it seems sensible have the big machines use multiple writers. But when these databases scale up, the database ends up sharded, with parts of the data spread over multiple machines. Why not just start there, with many small machines owning a small part of the database, and use just a single writer process. The application can then deal with concurrency, conflicts and assembling results, in whatever manner best suits. So I see the end goal to be a set of frameworks, and some “recipes” for putting the frameworks together, to solve the “persistence” problem. These are just half-baked ideas of course. I’ll follow the project, and hope to contribute. Yanni On Wed, Aug 10, 2022 at 7:08 AM Norbert Hartl <norb...@hartl.name> wrote: > FYI > > As the license situation around Omnibase is unlikely to change and such a > license is not an enabler for collaboration I came to the conclusion that > there is no other way than to start a new OO database (what a surprise! :) ) > > If you are interested or want to see what will happen in the next months > you can have a look at > > https://github.com/ApptiveGrid/Soil > > After half a day of work it can already serialize and partition a simple > graph and store it to disk in a way it can be read back even when > partitioned. Thanks to having Fuel we do not need to reinvent the wheel and > have serialization/materialization done. > Of course this is super simple and does not comes close to anything usable > but a good start. I've also added a documentation in the github repo to > describe the most important parts for me that I will target. > > Questions, critiques and laughs are appreciated, > > Norbert > > Am 08.08.2022 um 15:18 schrieb Norbert Hartl <norb...@hartl.name>: > > To all Omnibase and Monibase users. > > It turned out that neither of those are open source. The author of the > database contacted me clarifying the situation that he has the copyright > and never released something open source. This means that I will remove the > Omnibase repositories in few weeks from > > https://github.com/ApptiveGrid/MoniBase > > and > > https://github.com/pharo-nosql/OmniBase > > I'm very sorry about that but someone just took the code 9 years before, > copied it on github and put illegally an MIT license to the repository. We > only want free software in our repositories and hence the above will go > away. > > As we see it essential to have a good OO database in pharo we will see how > much effort it will be build a small and simple OO database that can > replace Omnibase. > > regards, > > Norbert > > >
