Scribo and persistency

Hi,

I think Scribo should have various persistency solutions. The first one
is of course the image, but what if someone wants to use GLORP, Magma,
some serialization, etc?

I took a look at Pier (hmm...) and it has a nice solution: an asbtract
class PRPierPersistency with subclasses, like ImagePersistency,
MagmaPersistency, etc

We could use something similar, and save the repository this way:

Repository>>persistency
        self otherAt: #persistency ifEmpty: [self otherAt: #persistency
put: ScriboImagePersistency newOn: self]

Repository>>setPersistency: aPersistencyClass
        self otherAt: #persistency (put: aPersistencyClass newOn: self)

Repository>>save
        self persistency saveRepository

Repository>>restore
        self persistency restoreRepository

etc...

What do you think ?

Cheers,

Nicolas
--
Nicolas Petton
http://nico.bioskop.fr
            ___
          ooooooo
         OOOOOOOOO
        |Smalltalk|
         OOOOOOOOO
          ooooooo
           \   /
            [|]
--------------------------------
Ma clé PGP est disponible ici :
http://nico.bioskop.fr/pgp-key.html

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Nicolas Petton wrote:

> Repository>>save
>         self persistency saveRepository
>
> Repository>>restore
>         self persistency restoreRepository

Keep in mind that simply saving the complete repository on every change
(or even every x minutes)

- doesn't scale
- isn't safe with concurrency

SqueakSource is a good (or bad) example how to not approach persistency.

Michael

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Le dimanche 10 février 2008 à 10:34 -0800, Michael Rueger a écrit : Yes, but this is only an example. The idea is to have several subclasses
of ScriboPersistency class. This way you'll have the choice. And we can
save only what's changed after every change.
>
> - doesn't scale
> - isn't safe with concurrency
>
So, what do you suggest ?

Nicolas

> SqueakSource is a good (or bad) example how to not approach persistency.
>
> Michael
>
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Nicolas Petton wrote:
Good question, I'm not really an expert on the different persistency
frameworks, just been bitten by the way SqueakSource ignores the whole
problem.
Disclosure: I think image persistency is the dumbest idea since I don't
know when... Saving your execution environment together with the data is
just a recipe for disaster, especially when new versions of the
application come out. How do you migrate your data forward?

The problem is that with the simple persistency like image persistency,
you just every now and then, or every change, invoke the save, which
simply saves everything. This is also true to some extent with Magma, as
far as I know.

If you use finer grained persistency you might need to keep track of
which objects you changed in a transaction and save them one by one. So
just using different subclasses might not be enough, your whole
application code might need to be built so it notes/signals/tracks changes.

Michael
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida