I think it depends how many objects you have and what your consistency
requirements are.
> Am 18.01.2024 um 05:48 schrieb sergio ruiz <sergio....@gmail.com>:
>
> I have been in the relational database world for decades. One of the things
> that is super simple is backing up and restoring data.
>
> Sometimes, it makes it makes sense to pull the production data into
> development. In the case of a catastrophe, it’s super simple to restore data
> from a backup.
>
> I am thinking of backup strategies for my data once again, and am wondering
> if things have changed since I was last using smalltalk.
>
> I am thinking of the following:
>
> STON
> I could dump all of my data into STON, but there is one slight twist. In this
> project, it’s just making a list of movie listings. There are three basic
> classes: Theater, Movie, Event. Each of these classes stores an
> OrderedCollection of items of that type on a class variable, as I’ll need to
> access each on their own.. so, if an event has a theater, I’ll need to access
> Theaters on their own, and Movies on their own.
>
> So, I would have to rebuild the list of Theaters from the Theaters in each
> event. Otherwise, I would lose the link between the Theaters on the Theater
> class variable and the Theater in the Event instance.
> Am I thinking about this incorrectly?
If you have three classes with class side collections you can have a make e.g.
a dictionary and put the collections from the class side into it like
model := {
#theaters -> Theater instances.
#movies -> Movie instances.
#event -> Event instances.
} asDictionary.
The model object you can use with STON or fuel to store it and on reading back
you store each of the values back on the class side variable. Simple and nice.
I would use STON for that because it is equivalent to fuel but fuel has
migration problems. Or better you need to load all your data, update fuel to a
newer version and write it again with the new fuel version. STON is more
reliable in that regard. Both have the problem that when objects change during
serialization you might corrupt the structure of your data,
>
> Gemstones
> I am totally into the idea of using gemstones. Is there a backup and restore
> for objects here? do the relationships remain?
>
GemStone is a huge thing to tame. I would not say the above and GemStone are
alternatives. GemStone is a lot to install and learn but you get something that
makes it hard to corrupt your data. So you have requirements that make it fit
into GemStone or you have requirements that make it a fit for STON. Between
both there is no overlap but rather a huge gap between the applicability of
each.
> Voyage
> This seems like a good solution, but I would rather stay in the smalltalk
> object store.
>
Absolutely. Voyage is good for some use cases but you have to deal with mongoDB
(not sure the small libraries work right now)
You could also consider using soil (https://github.com/ApptiveGrid/Soil)
I might be a bit biased here :) but for most use cases this is the best of all
the worlds described aboved. Even if there it has no release yet (coming soon)
it is quite stable.
Hope this helps,
Norbert
> Ideas?
>
> Thanks!
>
> ----
> peace,
> sergio
> photographer, journalist, visionary
>
> Public Key:
> https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> @sergio_101@mastodon.social
> https://sergio101.com
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
>
