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.