The conclusion I’ve come to, especially after seeing the success of ActiveRecord (a pattern I used to think sucked) in the Ruby community, is that nothing beats an explicit call to save by the programmer because it allows things to work outside of some special context where the auto-magic is available, and it’s easy for the programmer to see exactly what’s going on. Explaining how ActiveRecord’s work to another programmer and getting him productive fast is trivial, explaining how Glorp works and getting him *productive fast* is near impossible, too much magic for many programmers to keep in mind.

I’m becoming less and less a fan of magic and more and more a fan of simple straight forward solutions that just work (like saving objects to a file).

For those cases where the UI framework knows which action will be invoked on which object (e.g. the #on:of: style callbacks, or through some other means like the #actions in your SSForm), would it be possible for the logging to be done by the framework itself, rather than any explicit Command-pattern objects by the programmer? There seem to be multiple ways to do the wrapping, from method-wrappers to ByteSurgeon to …

- Bill

I was literally copying the code from FileStream to make it run, rather than modifying it. There are two differences between your code and what I had.

#readOnlyFileNamed:do: was using #detectFile:do:, which encapsulates the #ifNil:ifNotNil: call on file. And, my #readOnlyFileNamed looked like this:

readOnlyFileNamed: fileName
^ self concreteStream readOnlyFileNamed: (self fullName: fileName)

Which is where I got the #concreateStream and #fullName: methods.

I still don’t really get why it wouldn’t work before. Why would calling concreteStream from within ReferenceStream be any different than delegating it to FileStream?

Anyway, thank you for your help.

fileNamed: aName do: aBlock
	| file |
	file := self fileNamed: aName.
	^ file
		ifNil: [ nil ]
		ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ]

newFileNamed: aName do: aBlock
	| file |
	file := self newFileNamed: aName.
	^ file
		ifNil: [ nil ]
		ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ]

oldFileNamed: aName do: aBlock
	| file |
	file := self oldFileNamed: aName.
	^ file
		ifNil: [ nil ]
		ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ]

readOnlyFileNamed: aString
	| strm |
	strm := self on: (FileStream readOnlyFileNamed: aString).
	strm byteStream setFileTypeToObject.
	^ strm

readOnlyFileNamed: aName do: aBlock
	| file |
	file := self readOnlyFileNamed: aName.
	^ file
		ifNil: [ nil ]
		ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ]

I have been reading your blog for a while now, and enjoy it very much.

I have been working on an app to learn Seaside and Smalltalk recently and thought the idea in this post was great, but I have been having trouble making it work. I am pretty new to Squeak, so it is entirely possible I am missing something obvious.

I don’t think any of your code is the problem. #takeSnapshot works, #enablePersistance works. The problem is in #restoreRepositories in my subclass (GLDatabase). I have a single model class (SystemInfo with class instance var ‘repository’, and accessor/mutator for it) until I get it working.

Here is the relevant code:

SystemInfo class>>repository
respository ifNil: [self repository: #()].
^repository

GLDatabase class>>repositories
^Array with: (SystemInfo repository)

GLDatabase class>>restoreRepositories: someRespositories
SystemInfo repository: (someRepositories first)

I should note that I had to copy several methods (#concreteStream, #detectFile:do:, #fullName: and #readOnlyFileNamed:) which you did not mention, in order to get the code to run.

I made a little test to figure out where the problem is:

| written read |
Transcript clear.
ReferenceStream newFileNamed: ‘temp’ do: [: f|
written := f nextPut: #(#()).
f flush
].
read := ReferenceStream readOnlyFileNamed: ‘temp’ do: [ : f | f next ].

Transcript show: ‘written = ‘; show: written; cr;
show: ‘read = ‘; show: read; cr.

In my case the transcript reads:
written = #(#())
read = 

If I Ctrl-p on read, it says ‘Character backspace’, which explains why I was getting ‘Character doesNotUnderstand: #first’ error from #restoreRepositories.

I think the error is coming from #concreteStream

ReferenceStream>>concreteStream
“Who should we really direct class queries to? ”
^ MultiByteFileStream.

Am I supposed to be using a different Stream class for object serialization?

Anyway, sorry for the long comment. I hope someone can tell me what I am doing wrong.

Thanks

I like the idea very much - it is a bit more sophisticated that the simple ObjectFiler approach I am using in two of my (rather simple but handy) VSE programs. The absence of a backup is a bit annoying therem so I am thinking of adding something of your approach to that.

About the JPA poster: yes, it is interesting, but certainly overblown (as all J2EE stuff) for anything but real enterprise applications. And most even mid-sized companies simply do not need that.

Greetings from Germany,
Claus

Excellent post Ramon, one of my prefered…
Thanks a lot :)

Sophie

As for changing your classes (schema), it’s serialization, so just don’t change your class names and lazily initialize your instance variables in their accessors and you’re golden. New instance vars will be nil by default and get a value on first access, and inst vars you remove will just disappear.

However, since all the data is stored in the image anyway, you can just live upgrade the code and save a fresh backup and not worry so much about restoring old data. The backups are just that, backups, just in case, the real objects live in the image.

You can use Sixx streams instead of Ref streams if you prefer XML to a binary format, but it’s a lot slower, and you get much larger snapshot file sizes, so it won’t scale nearly as well as Ref streams.

Sophie, you’ve been very active on the list, you seem to have learned a lot, any chance you’ll take the plunge and start another Seaside blog?

One thing you might want to mention — I don’t’ know how ReferenceStreams handle changes to schema, in case you change things between save & restore. Could also mention SixxReadStream and SixxWriteStream as a (probably slower) option that might handle some schema changes a bit better.

Now if there was only a way to snapshot only those objects in the image that have changed since the last snapshot or “checkpoint”. In a way a “bulk” transaction without the bulk of saving each and every object each and every snapshot. Hey if it hasn’t changed the prior checkpoints or snapshots should have it - as long as you never delete the most recent FULL snapshot.

Otherwise most documentation of JPA is so rubbish that i stayed away from learning JPA for one week. (Specially Sun’s official Java EE Tutorial).

It’s all we all just need. Just simple persistence.

Being a class instance variable, I can’t use initialize since that’d initialize this superclasses lock rather than the subclasses required to use it. Each subclass has it’s own lock. I didn’t want every subclass to have to initialize it, so I chose this method given the insanely low chance you’d ever have a nil by the time you put it under multiple processes.

Thinking about it… maybe this is why some people prefer using an instance as a singleton rather than using the class instance itself, easier to initialize.

very interesting post. Thank you.

I have a doubt about your #saveRepository method.

saveRepository
lock ifNil: [ lock := Semaphore forMutualExclusion ].
lock critical: [...]

Imaging two process enter the method at the same time and lock is nil. They will both come into the #ifNil: block. Imagine the first process assign the instance variable lock and enter the #critical: block. Then, the second process override the instance variable and I don’t see anything preventing it from entering the #critical: block because the lock is not the same. What do you think?

Bye