[ANN] Soil release v1
...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast.
But now we are very happy to announce that Soil has a first public release v1. So what is soil?
Soil is an object oriented database in pharo http://pharo.org/. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ...
More details at https://github.com/ApptiveGrid/Soil
This release is still considered early stage because
although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;)
there are few things missing that you might expect like garbage collection, etc.
So but it is definetely usable and awaiting the brave ones of you to try.
Hopy you enjoy it!
Norbert & Marcus
That's really exciting news... appreciate you sharing it with the wider community (I know when you mentioned its existence a while back I went and watched the Esug recordings to get more info, and looked at some of the extensive test cases to get a feel on what it looked like - its neat).
Having multiple options for persisting data (from simple Fuel up to Soil and Glorp and Gemstone) is very useful.
Tim
On Wed, 24 Apr 2024, at 12:52 PM, Norbert Hartl wrote:
...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast.
But now we are very happy to announce that Soil has a first public release v1. So what is soil?
Soil is an object oriented database in pharo http://pharo.org/. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ...
More details at https://github.com/ApptiveGrid/Soil
This release is still considered early stage because
• although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;)
• there are few things missing that you might expect like garbage collection, etc.
So but it is definetely usable and awaiting the brave ones of you to try.
Hopy you enjoy it!
Norbert & Marcus
Esug-list mailing list -- esug-list@lists.esug.org
To unsubscribe send an email to esug-list-leave@lists.esug.org
Wonderful to hear. Unless mistaken, SOIL should support multiple open databases , so unless you expect intra-database consistency,since "you'll get an object back", it should "just work" for objects possibly instantiated from different DB's ?
From: Norbert Hartl norbert@hartl.name
Sent: Wednesday, April 24, 2024 1:53 PM
To: Pharo users users pharo-users@lists.pharo.org; Pharo Dev pharo-dev@lists.pharo.org; ESUG esug-list@lists.esug.org
Subject: [Pharo-dev] [ANN] Soil release v1
...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast.
But now we are very happy to announce that Soil has a first public release v1. So what is soil?
Soil is an object oriented database in pharohttp://pharo.org/. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ...
More details at https://github.com/ApptiveGrid/Soil
This release is still considered early stage because
- although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;)
- there are few things missing that you might expect like garbage collection, etc.
So but it is definetely usable and awaiting the brave ones of you to try.
Hopy you enjoy it!
Norbert & Marcus
Hi,
Am 24.04.2024 um 19:28 schrieb Miloslav.Raus--- via Pharo-dev <pharo-dev@lists.pharo.org>:
@font-face { font-family: Wingdings; }
@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: "Times New Roman", serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
a:visited, span.MsoHyperlinkFollowed { color: purple; text-decoration: underline; }
p.msonormal0, li.msonormal0, div.msonormal0 { margin-right: 0cm; margin-left: 0cm; font-size: 12pt; font-family: "Times New Roman", serif; }
span.StylE-mailovZprvy18 { font-family: Calibri, sans-serif; color: rgb(31, 73, 125); }
.MsoChpDefault { font-size: 10pt; }
@page WordSection1 { size: 612pt 792pt; margin: 70.85pt; }
div.WordSection1 { page: WordSection1; }
ol { margin-bottom: 0cm; }
ul { margin-bottom: 0cm; }Wonderful to hear. Unless mistaken, SOIL should support multiple open databases , so unless you expect intra-database consistency,since „you’ll get an object back“, it should „just work“ for objects possibly instantiated from different DB’s ?
I have trouble understanding what you mean. Can you elaborate on that?You mean multiple open databases on the same data on different images? As long as you don‘t use indexes it should work. But I think this is only a good option in very rare cases.
Norbert
From: Norbert Hartl <norbert@hartl.name>
Sent: Wednesday, April 24, 2024 1:53 PM
To: Pharo users users <pharo-users@lists.pharo.org>; Pharo Dev <pharo-dev@lists.pharo.org>; ESUG <esug-list@lists.esug.org>
Subject: [Pharo-dev] [ANN] Soil release v1...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast.
But now we are very happy to announce that Soil has a first public release v1. So what is soil?
Soil is an object oriented database in pharo. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ...
More details at https://github.com/ApptiveGrid/Soil
This release is still considered early stage because
- although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;)
- there are few things missing that you might expect like garbage collection, etc.
So but it is definetely usable and awaiting the brave ones of you to try.
Hopy you enjoy it!
Norbert & Marcus
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?
Thanks again,
Sean
Am 30.06.2024 um 05:41 schrieb sean@clipperadams.com:
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
Hi norbert
I love the idea behind soil :)
That you keep pushing it is just great.
I will start to play with it during holidays.
S
On 30 Jun 2024, at 20:37, Norbert Hartl norbert@hartl.name wrote:
Am 30.06.2024 um 05:41 schrieb sean@clipperadams.com:
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
Stéphane Ducasse
http://stephane.ducasse.free.fr
06 30 93 66 73
"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.” Calvin & Hobbes