Note that we get a NotYet error. This indicates that we might be able
to get a key reference later.

We can get references to unsaved objects if they have an adapter to
ZODB.interfaces.IConnection. The add method on the connection
will be used to give the object an object id, which is enough
information to compute the reference. To see this, we’ll create an
object that conforms to IConnection in a silly way:

Conflict Resolution

During conflict resolution, as discussed in ZODB/ConflictResolution.txt,
references to persistent objects are actually instances of
ZODB.ConflictResolution.PersistentReference. This is pertinent in two ways
for KeyReferenceToPersistent. First, it explains a subtlety of the class: it
does not inherit from persistent.Persistent. If it did, it would not be
available for conflict resolution, just its PersistentReference stand-in.

Second, it explains some of the code in the __hash__ and __cmp__
methods. These methods not only handle persistent.Persistent objects,
but PersistentReference objects. Without this behavior, objects, such
as the classic ZODB BTrees, that use KeyReferenceToPersistent as keys or
set members will be unable to resolve conflicts. Even with the special
code, in some cases the KeyReferenceToPersistent will refuse to compare
and hash during conflict resolution because it cannot reliably do so.

__hash__ will work relatively rarely during conflict resolution: only for
multidatabase references. Here are a couple of examples.