Norbert,
I'm very interested to investigate Soil. Do you have examples on how to
use Soil?
I currently use a STON persistence model. My current approach to my model
is structured specifically to make STON full save and restores simple...
- Wrapper Class which contains a collection of high level objects
- high level objects contain collections of next level objects
- next level objects contain collections of lower level objects
- etc.
While the database size (7.3Mb) is not terribly large, I am writing about
50 of those per day as each save simply saves off the entire old STON and
writes a new one. Concurrency is generally not a problem as we have the
application automatically save itself every 10 minutes, but every once in a
while we do run up against a conflict that would be best handled by a
concurrent capable model.
I have roughly nine applications using the same class models, so it would
be very helpful to adopt a more OO database approach to persistence... even
though we're nowhere near Google :)
Thoughts on where to begin? I'm on the Discord server as well, if you'd
prefer to discuss there.
Thanks,
Russ
On Thu, Feb 15, 2024 at 4:49 AM Norbert Hartl <norb...@hartl.name> wrote:
> The approach as I understand is simple and valuable until you face
> concurrency. Nothing in SimplePersistence prevents your data from becoming
> corrupt in a concurrent situation. I agree that when you start a project
> you almost never face concurrency because the odds are way too low to have
> two things at the same time happening. This is because computers are really
> fast today and the amount of activity on a service is largely overestimated.
>
> But there is still a huge gap between SimplePersistence and those overkill
> persistence solutions. For exactly that reason I've done Soil (
> https://github.com/ApptiveGrid/Soil) to fill that gap. It is one project
> with no dependency and setting it up is a no-brainer. It is way bigger than
> SimplePersistence but it deals with concurrency and adds query capabilties
> for your objects. But you have to use transactions to do this.
>
> I started ApptiveGrid just by having the data persisted through saving the
> image. Next was to STON out the model. Then versioned STON files to add
> fallback. Then there was Soil (well, first voyage and then omnibase and
> then Soil) which is the next level to iterate.
>
> So ApptiveGrid is not the next google but it also wouldn't work with
> SimplePersistence. So good that we have enough tools to improve our
> projects on.
>
> Norbert
>
>
> Am 15.02.2024 um 06:43 schrieb s...@clipperadams.com:
>
> I’m happy to answer any questions about Simple Persistence. It is a nice
> framework around (potentially any) serializer. It’s meant to be pluggable
> but currently uses Fuel out of the box. You just tell it what classes to
> persist and then create two methods per class to handle
> materialization/serialization.
>
> For the record, Ramon Leon created it in a blog post. I just ported it to
> Pharo and have been maintaining it.
>
> The stated reason he created it is that most solutions are complete
> overkill for 99% of projects that will never “become the next google”. It’s
> pretty basic, but at least two steps more sophisticated than simply saving
> the image because it keeps old versions and is easily reloadable into
> another image.
>
> That said, I’ve been using it almost exclusively for my personal projects
> and have yet to grow out of it.
>
>
>
--
Russ Whaley
whaley.r...@gmail.com
