> I'm not sure I understand your question.  If you don't have something
> special you want to do by subclassing Rack, then the answer would be
> "no".  :)

You do answer my question below.  I was wondering if this line would not
cause an object to be stored in the ZODB by default.

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

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.

Besides writing some skinscript and sql methods is there anything else one
should do to only use non-ZODB storage.  When will I use attribute and
sheetproviders and do they come into play at all with non-ZODB storage.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to