Next: Using Transactions, Previous: Persistent Classes, Up: Tutorial
Using the persistent-metaclass
metaclass declares all slots to
be persistent by default. To make a non-persistent slot use the
:transient t
flag. Class slots are never persisted, for either
persistent or ordinary classes. (Is this the right behavior?)
Readers, writers, accessors, and slot-value-using-class
are
instrumented, so override these with care. Because slot-value,
slot-unboundp, slot-makunbound
are not generic functions, they are
not guaranteed to work properly with persistent slots. Use the
*-using-class
versions or the closer-to-mop
MOP compliance
layer by Pascal Costanza (we may integrate this in later versions).
Persistent classes may inherit from other classes. Slots inherited from persistent classes remain persistent. Transient slots and slots inherited from ordinary classes remain transient. Ordinary classes cannot inherit from persistent classes – persistent slots need to get stored!
Note that the database is read every time you access a slot. This is a feature, not a bug, especially in concurrent situations: you want the most recent commits, right? (Sleepycat will give isolation inside of transactions, though.) Note that this can be used as a weak form of IPC. But also note that in particular, if your slot value is not an immediate value, reading will cons the value. Gets are not an expensive operation (I can do a million reads in 30 seconds), but if you're concerned, cache values. In the future we will provide automatic value caching – "single user mode."
Finally, if you for some reason make an instance with a specified OID
which already exists in the database, initargs
take precedence
over values in the database, which take precedences over
initforms
. Also currently there is a bug where
initforms
are always evaluated, so beware.
(What is the current model here?)