[Pharo-users] Re: Backing up data

[Norbert Hartl]

Hi Russ, stay tuned, we are preparing a 0.1 release for Soil before or at the time of pharo12 release. With 0.1 we will document how to use it.  If you use STON it will be similar because if you do  db := Soil path: ‚mydb‘. db initializeFilesystem. txn := db newTransaction. txn root: yourModelRoot. txn commit. it will save all of the 7,3 MB in the database. Every time you do  txn := db newTransaction. txn root it will read all of the model you have just write now but concurrent safe. Optimizing this is partitioning your graph and saying which of your objects are standalaone by saying txn makeRoot: anObject. then only the needed parts of your model are loaded. But in order to save it you have to mark the objects you made root dirty by saying txn markDirty: anObject That‘s all for basic usage. For the rest you need to wait for the documentation. Norbert Am 17.02.2024 um 19:47 schrieb Russ Whaley <whaley.r...@gmail.com>:  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