Dale, there is really no need for an excusion :) I found your pointer really informative and what you are saying is always interesting. But yeah, Yanni has a point here. I was pretty satisified with Omnibase because it is easy to handle being smalltalk and running in the same image. Supporting ACID transactions with MVCC is even a strong point. Performance is an important point. But performance is mostly defined by the use case and the architecture you choose for that. And our setup can scale out quite well I suppose.
Norbert > Am 08.08.2022 um 22:34 schrieb Dale Henrichs > <dale.henri...@gemtalksystems.com>: > > Sorry to have interrupted ... I just remember that folks have moved from > OmniBase to GemStone in the past for "performance reasons" and understand > that those aren't the only reasons for having an OmniBase replacement ... > > Dale > > On Mon, Aug 8, 2022 at 10:22 AM Yanni Chiu <yannix...@gmail.com > <mailto:yannix...@gmail.com>> wrote: > Dale, > > It’s not about inventing a “database”, it’s a requirement to persist data > beyond image start/stop, along with intangibles like having the full source > code to tune for individual requirements. In my case the top (desired) > requirements are single directory or file per user (scaling), and no > additional server process(es) to be monitored for failure mode. > > Yanni > > On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs > <dale.henri...@gemtalksystems.com <mailto:dale.henri...@gemtalksystems.com>> > wrote: > Norbert, > Before you go off and invent a data base, you might take a look at GemStone > and RemoteServiceReplication[1] ... > > Dale > > [1] https://github.com/GemTalk/RemoteServiceReplication > <https://github.com/GemTalk/RemoteServiceReplication> > On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norb...@hartl.name > <mailto:norb...@hartl.name>> wrote: > 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 > <https://github.com/ApptiveGrid/MoniBase> > > and > > https://github.com/pharo-nosql/OmniBase > <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
