Magma for Squeak Persistency
Locked
 
|
All, can someone give me some pointers on using Magma as a Storage-Backend for Pier2. I've only found references to Pier/Seaside28 in PierAddons - none for Pier2/Seaside3. Best Regards, Udo _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
AFAIK, there were various attempts at using Magma as a storage
backend, but none of them was successful :-( Lukas On 4 December 2010 08:11, Udo Schneider <[hidden email]> wrote: > > All, > > can someone give me some pointers on using Magma as a Storage-Backend for > Pier2. I've only found references to Pier/Seaside28 in PierAddons - none for > Pier2/Seaside3. > > Best Regards, > > Udo > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
I had not heard about any attempts to do this. Do you know why they
were not successful? I would like to reiterate, once again, my support for Magma; that if anyone is trying and failing to do something, I'd be happy to help. All you have to do is ask. - Chris On Sat, Dec 4, 2010 at 5:40 AM, Lukas Renggli <[hidden email]> wrote: > AFAIK, there were various attempts at using Magma as a storage > backend, but none of them was successful :-( > > Lukas > > On 4 December 2010 08:11, Udo Schneider <[hidden email]> wrote: >> >> All, >> >> can someone give me some pointers on using Magma as a Storage-Backend for >> Pier2. I've only found references to Pier/Seaside28 in PierAddons - none for >> Pier2/Seaside3. >> >> Best Regards, >> >> Udo >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
> I had not heard about any attempts to do this. Do you know why they
> were not successful? You wrote to me in Dezember 2009: "I will obviously be interested in persisting my Pier sites in Magma. I have examined the Pier model and grok'd the code related to persistency, and from this have coded a new Persistency subclass, PRMagmaPersistency (14 methods)." I said: "Another thing I should warn you about is that Pier scans its complete object graph whenever a page is edited, moved, copied, removed, etc. The same happens when a live search is performed or when a page is displayed with all its references enumerated. This basically made my initial attempt of a persistency strategy using GOODS back in 2003 impossible. I don't know, but I guess this might be a problem for Magma too, when the complete object graph is traversed several times for every request?" After a few more mails back and forth I haven't heard anything anymore, so I assumed the project failed. There are is a Pier-Magma package in <http://source.lukas-renggli.ch/pieraddons> (and a few others that mention Magma in some commits). I am not sure if they are used and working. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
Well, that project didn't "fail," I just had to move on to other work
and have not had a chance to return to it. Traversing the entire object model a lot would certainly require it to be fully materialized into memory, so Magma (or any persistence framework) wouldn't really allow Pier models to effectively move beyond the size of available RAM. But the use of Magma could be beneficial in terms of safety; much safer than "image persistence" since every commit is verified with SHA1, and you can replicate and roll-back the model if necessary, etc. On Sat, Dec 4, 2010 at 2:49 PM, Lukas Renggli <[hidden email]> wrote: >> I had not heard about any attempts to do this. Do you know why they >> were not successful? > > You wrote to me in Dezember 2009: > > "I will obviously be interested in persisting my Pier sites in Magma. > I have examined the Pier model and grok'd the code related to > persistency, and from this have coded a new Persistency subclass, > PRMagmaPersistency (14 methods)." > > I said: "Another thing I should warn you about is that Pier scans its > complete object graph whenever a page is edited, moved, copied, > removed, etc. The same happens when a live search is performed or when > a page is displayed with all its references enumerated. This basically > made my initial attempt of a persistency strategy using GOODS back in > 2003 impossible. I don't know, but I guess this might be a problem for > Magma too, when the complete object graph is traversed several times > for every request?" > > After a few more mails back and forth I haven't heard anything > anymore, so I assumed the project failed. > > There are is a Pier-Magma package in > <http://source.lukas-renggli.ch/pieraddons> (and a few others that > mention Magma in some commits). I am not sure if they are used and > working. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
Of course it would be great to have Magma provide additional safety;
the possibility to easily move between images; the possibility to roll-back; and maybe even serve the same model from different images; ... Lukas On 4 December 2010 19:10, Chris Muller <[hidden email]> wrote: > Well, that project didn't "fail," I just had to move on to other work > and have not had a chance to return to it. > > Traversing the entire object model a lot would certainly require it to > be fully materialized into memory, so Magma (or any persistence > framework) wouldn't really allow Pier models to effectively move > beyond the size of available RAM. > > But the use of Magma could be beneficial in terms of safety; much > safer than "image persistence" since every commit is verified with > SHA1, and you can replicate and roll-back the model if necessary, etc. > > > On Sat, Dec 4, 2010 at 2:49 PM, Lukas Renggli <[hidden email]> wrote: >>> I had not heard about any attempts to do this. Do you know why they >>> were not successful? >> >> You wrote to me in Dezember 2009: >> >> "I will obviously be interested in persisting my Pier sites in Magma. >> I have examined the Pier model and grok'd the code related to >> persistency, and from this have coded a new Persistency subclass, >> PRMagmaPersistency (14 methods)." >> >> I said: "Another thing I should warn you about is that Pier scans its >> complete object graph whenever a page is edited, moved, copied, >> removed, etc. The same happens when a live search is performed or when >> a page is displayed with all its references enumerated. This basically >> made my initial attempt of a persistency strategy using GOODS back in >> 2003 impossible. I don't know, but I guess this might be a problem for >> Magma too, when the complete object graph is traversed several times >> for every request?" >> >> After a few more mails back and forth I haven't heard anything >> anymore, so I assumed the project failed. >> >> There are is a Pier-Magma package in >> <http://source.lukas-renggli.ch/pieraddons> (and a few others that >> mention Magma in some commits). I am not sure if they are used and >> working. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
In reply to this post by Lukas Renggli
Lukas,
On 04.12.2010, at 21:49, Lukas Renggli wrote: >> I had not heard about any attempts to do this. Do you know why they >> were not successful? > > You wrote to me in Dezember 2009: > > "I will obviously be interested in persisting my Pier sites in Magma. > I have examined the Pier model and grok'd the code related to > persistency, and from this have coded a new Persistency subclass, > PRMagmaPersistency (14 methods)." > > I said: "Another thing I should warn you about is that Pier scans its > complete object graph whenever a page is edited, moved, copied, > removed, etc. The same happens when a live search is performed or when > a page is displayed with all its references enumerated. This basically > made my initial attempt of a persistency strategy using GOODS back in > 2003 impossible. I don't know, but I guess this might be a problem for > Magma too, when the complete object graph is traversed several times > for every request?" > Editing does not change the structure. It can create outgoing links that need to be looked up. Moving to me includes managing of children if you move it to another hierarchy. But the incoming links still just point to the same objects. I don't know what is needed for copying. For removing neither it just produces broken incoming links. Did I miss a lot of things I'm not aware of? Would be kind to shed some light. Thanks! Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
In reply to this post by Lukas Renggli
I /think/ I got the idea of what's involved ...
A few questions though: 1) Is my assumption correct that every change to a Pier Kernel take the route through PRPersistency>>#execute:? 2) Let's say I got an complex objectgraph from Magma ... will this objectgraph be nilled out at the end/refresh of the transaction or will the materialized object still exist in memory as long as they are not GCed? Thanks, Udo On 05.12.10 00:00, Lukas Renggli wrote: > Of course it would be great to have Magma provide additional safety; > the possibility to easily move between images; the possibility to > roll-back; and maybe even serve the same model from different images; > ... > > Lukas > > On 4 December 2010 19:10, Chris Muller<[hidden email]> wrote: >> Well, that project didn't "fail," I just had to move on to other work >> and have not had a chance to return to it. >> >> Traversing the entire object model a lot would certainly require it to >> be fully materialized into memory, so Magma (or any persistence >> framework) wouldn't really allow Pier models to effectively move >> beyond the size of available RAM. >> >> But the use of Magma could be beneficial in terms of safety; much >> safer than "image persistence" since every commit is verified with >> SHA1, and you can replicate and roll-back the model if necessary, etc. >> >> >> On Sat, Dec 4, 2010 at 2:49 PM, Lukas Renggli<[hidden email]> wrote: >>>> I had not heard about any attempts to do this. Do you know why they >>>> were not successful? >>> >>> You wrote to me in Dezember 2009: >>> >>> "I will obviously be interested in persisting my Pier sites in Magma. >>> I have examined the Pier model and grok'd the code related to >>> persistency, and from this have coded a new Persistency subclass, >>> PRMagmaPersistency (14 methods)." >>> >>> I said: "Another thing I should warn you about is that Pier scans its >>> complete object graph whenever a page is edited, moved, copied, >>> removed, etc. The same happens when a live search is performed or when >>> a page is displayed with all its references enumerated. This basically >>> made my initial attempt of a persistency strategy using GOODS back in >>> 2003 impossible. I don't know, but I guess this might be a problem for >>> Magma too, when the complete object graph is traversed several times >>> for every request?" >>> >>> After a few more mails back and forth I haven't heard anything >>> anymore, so I assumed the project failed. >>> >>> There are is a Pier-Magma package in >>> <http://source.lukas-renggli.ch/pieraddons> (and a few others that >>> mention Magma in some commits). I am not sure if they are used and >>> working. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Magma for Squeak Persistency
|
|
In reply to this post by NorbertHartl
> Editing does not change the structure. It can create outgoing links that need to be looked up. Moving to me includes managing of children if you move it to another hierarchy. But the incoming links still just point to the same objects. I don't know what is needed for copying. For removing neither it just produces broken incoming links. Did I miss a lot of things I'm not aware of?
Yes, you are right about editing. Check the implementations of #doExecute in the subclasses of PRCommand. - Removing needs to traverse the complete tree to nil out references, otherwise the removed page would stick around. - Moving and copying needs to ensure that the paths are properly updated. Pier remembers the path string in references to be able to regenerate an identical wiki string. This could be optimized and would make this traversal unnecessary. - Searching for text or for incoming references obviously needs to traverse the complete graph. Again this could be indexed, but would need some work. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |