[Zope-dev] ZPatterns: Non-ZODB storage and Racks

[Phillip J. Eby]

At 10:51 PM 11/8/00 +200, Roch'e Compaan wrote:
>
>> The comment is perhaps misleading.  What it means is that the _setSlot
>> call isn't needed if your Rack implements a non-ZODB storage mechanism. 
>> The reason *why* it isn't needed, is that the DataSkin will ask for a
>> slot on demand, so that a ZODB record is only created if something needs
>> to be stored persistently.  However, in the case where you have not set
>> a "load" attribute (i.e., you are storing actual objects in the ZODB),
>> then one might as well tell the object its slot, because the slot is
>> where the object itself is going to be stored.  Technically, the
>> _setSlot call isn't necessary even then, because the DataSkin could
>> still ask for it on demand.
>>  However, since the code at this point has gone to the trouble of
>>  getting
>> the slot object, it might as well pass it to the DataSkin immediately.
>
>Here I loose you.  What does "setting the load attribute" mean?

On the "Storage" tab there is an option to store instances persistently, or
else to load them by accessing a particular attribute.  Choosing that
option is "setting the load attribute".


>I did manage to store objects in a SQL RDBMS through some skinscript
>methods that call sql methods.  I assumed selecting a ZClass on the
>storage tab simply informs the ZClass what it's rack is. I couldn't verify
>if these objects were stored in the ZODB as well as in my RDBMS.

It's determined by the radio button setting on the Storage tab.  If you
neglected to set it to "loaded by accessing attribute ____" and fill in the
blank, then your objects have been stored in the ZODB, as well as in the
RDBMS.

Even if you did set the Storage tab correctly, you could still have data in
the ZODB for your objects, if you set an attribute that did not have a
handler, and you left the default attribute providers in place.  Or, if you
added WebDAV property sheets to an object, that would have caused data to
be stored in the ZODB as well.


>Besides writing some skinscript and sql methods is there anything else one
>should do to only use non-ZODB storage.

Make sure the storage tab is set to not store the objects themselves
persistently.


>  When will I use attribute and
>sheetproviders and do they come into play at all with non-ZODB storage.

They don't, unless you write some custom ones of your own.