2.7 Rules about Persistent Classes

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?)