4 Dec
2010
4 Dec
'10
12:11 p.m.
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
4 Dec
4 Dec
12:40 p.m.
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 <udo.schneider(a)homeaddress.de> 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
6:58 p.m.
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 <renggli(a)gmail.com> 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 <udo.schneider(a)homeaddress.de> 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
9:49 p.m.
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
11:10 p.m.
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 <renggli(a)gmail.com> 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
5 Dec
5 Dec
midnight
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 <asqueaker(a)gmail.com> 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 <renggli(a)gmail.com> wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Lukas Renggli
www.lukas-renggli.ch
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
6 Dec
6 Dec
8:18 a.m.
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<asqueaker(a)gmail.com> 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<renggli(a)gmail.com> wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
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
5 Dec
5 Dec
11:55 a.m.
Lukas,
On 04.12.2010, at 21:49, Lukas Renggli wrote:
can you please elaborate a little on the specific actions that take place. I know
pier does a lot of traversal. But if I think about it I don't have a lot of ideas why
this is necessary.
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
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?"
6 Dec
6 Dec
6:59 p.m.
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
4915
days inactive
4917
days old
8 comments
4 participants
participants (4)
-
Chris Muller -
Lukas Renggli -
Norbert Hartl -
Udo Schneider