This post originated from an RSS feed registered with Python Buzz
by Ng Pheng Siong.
Original Post: Being Agile
Feed Title: (render-blog Ng Pheng Siong)
Feed URL: http://sandbox.rulemaker.net/ngps/rdf10_xml
Feed Description: Just another this here thing blog.
I've started a few threads before on object
persistence in medium to high end server apps.
This one is about low end apps [...]
In no particular order, these were suggested: ZODB, SQLobject, serialised pickles, (py)bsddb, using the filesystem and OS locking, Metakit, SQLite and KirbyBase.
In Smalltalk, the simplest persistence mechanism is the image. To quote a 1995
Usenet post,
Because Smalltalk operates on an "image" of
its object space, and because that image is
usually stored in a file, if a Smalltalk application
hangs objects off some well-known object,
and then it or user of the application saves
the image back to its file, one could genuinely
say that the objects are persistent.
I've been prototyping an application in Squeak. I use workspace variables to hold object references; as described in the quote above, I'm getting object persistence "for free".
My software models, among other things, events, which mark happenings in the virtual world of my application. Most of the time, events are generated by user interface interactions. My prototype doesn't yet have a UI; for
now, events are generated by Smalltalk messaging. I need the events to be persistent.
In the c.l.py discussion, a poster wrote,
The KirbyBase distribution comes with two
small scripts that each implement a server.
[...]
kbthreadedserver.py also allows for
multi-user access. It creates a multi-threaded,
non-blocking server. [...]
Either of these server scripts would have to
be running as a process either on your web
server or on another server on your network
in order for them to work. I don't know if
that would be an issue for you.
My application wants to generate periodic events, i.e., events that always occur, at fixed intervals, without user interaction. If I'm developing in Python, I see two ways to do this:
» Run an object server, e.g., the KirbyBase one, as a separate process and do IPC with it from other Python programs fired by cron, say.
» Embed the object server into my application, and start a thread that does the periodic event generation.
Either way, I need at least one long-running Python process, preferrably with an accessible REPL with which to manipulate my application's objects interactively.
Now, this application is for something that I'm doing right now. Even as I'm prototyping, I sometimes post real events which I want to preserve; these include most of the periodic events.
With Python, I'll be coding in vim. Whenever I modify my domain objects, I'll have to restart the long-running process to load their new behaviour. I need maintenance scripts, e.g., to kill off and repopulate entire object trees containing events and other domain stuff, while keeping some of them. These scripts will be specific to the object persistence system in use. If I switch from, say, KirbyBase, to, I dunno, ZODB, the scripts must change. (And then it's easy to get sidetracked into fussing about the source code
version control system of choice, yada yada.)
With Smalltalk, a lot of the necessary infrastructure comes for free. I simply fire off a Squeak process for my periodic event generation - the Smalltalk world itself acts as the object server. When I modify code in a browser, existing objects get the new behaviour, without my needing to reload or whatever. I keep chunks of ad hoc maintenance code around in a workspace. When I save the image, all these are saved.
Bottom line: I get to focus on domain modeling. Infrastructure decisions can be delayed for as long as possible.
Previous Topic
