[ZODB-Dev] Re: [Zope] DateTime mess

[Tim Peters]

...

>>> ...have we just committed a pickle containing all of 'a'?...

>> If `a` is persistent, yes.

> If not?

Then get_transaction().commit() presumably doesn't do much of anything,
since no persistent object was changed.  It's like asking what this does:

    i = 2+3
    get_transaction().commit()

Well, "probably nothing (of any interest)".

...

>> One part is different:  if DateTime is not persistent, then the pickle
>> for a's state includes the full state of a.someTime's DateTime attribute
>> (and this is true for any attribute of any non-persistent type).  But if
>> DateTime is persistent, then a.someTime is pickled as a distinct object,
>> and the state for `a` contains only a reference to that distinct pickle
>> (and again this is true for any attribute of any persistent type).  a's
>> full state is pickled regardless.  The difference is in whether a's full
>> state embeds a.someTime's state directly, or "points to" a distinct
>> pickle for a.someTime's state.

> Ah, okay, so having DateTime sublcass Persistent would only really matter
> if a had _lots_ of DateTime attributes.

Matter to what, specifically?  I don't see the connection.  If many
persistent objects reference the _same_ DateTime object (identically the
same:  "d1 is d2" in Python terms, not merely "d1 == d2"), then making
DateTime persistent would allow those objects' states all to refer to a
single physical pickle for that DateTime object.  That has nothing to do
with the sheer number of DateTime attributes, though, it has entirely to do
with how often the app can and does force DateTime attributes to reference
identically-same DateTime objects.

If there are a large number of DateTime attributes that are rarely
referenced, then there can be a different reason to want DateTime to be
persistent:  ZODB creates "ghosts" for attributes of persistent types when
an object is loaded, and if a persistent attribute is never referenced then
ZODB never needs to fetch its state or consume RAM to materialize its state.
In contrast, attributes of non-persistent types are fully materialized when
the containing object is loaded.

> Does this ever happen?

Don't know but I doubt it's common.  It's plausible, e.g., that you've got
an app managing, say, the open/closed schedules for buildings on a campus,
and want to say that each building closes at 8pm 31 Dec and doesn't reopen
until 8am 7 Jan.  Then the buildings _could_ share the same DateTime objects
representing the endpoints of their common schedule that week.  Anyone
contorting their code to force that to happen is probably insane, though ;-)