17 Jan
2007
17 Jan
'07
6:24 p.m.
- PRPathLookup
class>>star:path: you removed that, but it is
needed all trough the system
Sorry I dont think that I meant to remove that method. Its the Pier-
Caching package that is supposed to hook in to these methods. - PRCommand: I
moved the mutex from the kernel into the
persistency, it seems to belong there so that we don't violate
demeter. Now instad of having the critical section within the
command, the command passes itself to the persistency by sending
#execute:. The persistency strategy then can call #doValidate and
#doExecute at the right point in time. I think this is more
elegant and should even work better with object database, xml, ...
sounds good - I don't
understand the code to rename a kernel (why should that
matter?) and the code
Because the kernel is looked up by name in the database. But once everything is set up, what if you want to
change things. I
do frequently. I expect my image to change frequently, and my
persistent store to hold my data.
With my approach you can switch between persistency schemes on the
fly. I thought that it was quite flashy to be able to switch from
"everything in memory", "everything in memory, back up to
persistent store" persistence to full "serve from persistent store".
That's cool, I completely agree.
At your suggestion I guess I could begin a
Pier-Persistency-Manager
package to put this and the migration methods in.
Yep, that sounds nice to me.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
17 Jan
17 Jan
9:04 p.m.
New subject: Magritte Post
Keith
may be you should give a cool name to your persistency framework.
Let us think marketing. Docker? Docks?
Stef
On 17 janv. 07, at 18:24, Lukas Renggli wrote:
Then this must be caused by the subsequent merges of the different
branches ...
Yes, this seems to be much more logical to me. It does not enforce
the prevayler model (snapshot/changes) to the persistency, but let it
basically do anything it likes: before a command is executed, between
the validation and the execution, after the execution, etc.
Why don't you give your persistency strategy a unique id then? Pier
(currently) does not enforce unique names for kernels.
- PRPathLookup class>>star:path: you removed
that, but it is
needed all trough the system
Sorry I dont think that I meant to remove that method. Its the Pier-
Caching package that is supposed to hook in to these methods. -
PRCommand: I moved the mutex from the kernel into the
persistency, it seems to belong there so that we don't violate
demeter. Now instad of having the critical section within the
command, the command passes itself to the persistency by sending
#execute:. The persistency strategy then can call #doValidate and
#doExecute at the right point in time. I think this is more
elegant and should even work better with object database, xml, ...
sounds good - I
don't understand the code to rename a kernel (why should that
matter?) and the code
Because the kernel is looked up by name in the database. But once everything is set up, what if you want
to change things. I
do frequently. I expect my image to change frequently, and my
persistent store to hold my data.
With my approach you can switch between persistency schemes on the
fly. I thought that it was quite flashy to be able to switch from
"everything in memory", "everything in memory, back up to
persistent store" persistence to full "serve from persistent store".
That's cool, I completely agree.
At your suggestion I guess I could begin a
Pier-Persistency-Manager
package to put this and the migration methods in.
Yep, that sounds nice to me.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
6575
days inactive
6575
days old
1 comments
2 participants
participants (2)
-
Lukas Renggli -
stéphane ducasse