[Zope] Subclassing from Custom Python Classes

[Pete Kazmier]

Thank you for the useful information!!

I do have one more question regarding your persistence comments.  How
does using a temporary name notify the Zope persistence machinery that
self.map has changed?  Doesn't 'self.map=m' do nothing in Python if
one already did a 'm=self.map'?  In the end, aren't they referencing
the exact same object?  Hows does Zope know its different?

Thanks again,
Pete

On Wed, May 24, 2000 at 12:38:03AM -0400, Chris McDonough wrote:
> > >> You should also note that your subclass must obey the ZODB
> > >> persistence rules, which basically state that mutable sub-objects
> > >> should be treated immutably. For example,
> > >>
> > >> self.bird='parrot' # OK
> > >> self.map['bird']='parrot' # NOT OK, will not trigger persistence
> > >>                             machinery
> > >> m=self.map
> > >> m['bird']='parrot'
> > >> self.map=m # OK, treats a mutable object immutably
> > 
> > What are these "persistence rules" and how come the second example is
> > ok?  I thought in Python, when you assign "m = self.map" that m is
> > simply pointing to the same object as self.map and that any changes to
> > m affect self.map too?  Does the "self.map = m" have any effect?
> > Don't they point to the same object?
> 
> It's a long story.  :-)  Attributes of Zope objects need to play by some
> ground rules to be persistent.  The description in the docs is sort of a
> half truth.  It works as described, but you can also do something like:
> 
> self.map['bird'] = 'parrot'
> self._p_changed = 1
> 
> to trigger the persistence machinery.  The "m=self.map..." stuff in the
> example does the same thing.  In either case you're bringing it to
> Zope's attention that it needs to at some point re-write the object
> referred to by "self" out to the ZODB.  By doing the jiggery up there
> where you use "m" as a temp object, operate on it, and then reassign
> "self.map" to "m" in order to let Zope know you've really changed the
> object and that you really want to write a new copy of it out to the
> ZODB when it's convenient for it to do so.  the _p_changed flag applies
> to any Zope object, and just needs to be set true at some point during
> the method to let the persistence machinery know that the object has
> changed state.
> 
> In english the phrase "mutable sub-objects should be treated immutably"
> means that attributes of the Zope object you're mucking with that can be
> reassigned "in-place" (things you can append to like a list, or add
> items to like a dictionary) should be treated as though they can't be.
> So when saying (where 'self' is a Zope object):
> 
> self.mylist.append("foo")
> 
> This should be given special treatment, either by saying:
> 
> self.mylist.append("foo")
> self._p_changed = 1
>  
> or
> 
> mytmp = self.mylist
> mytmp.append("foo")
> self.mylist = mytmp
> 
> > 
> > I ask because I've already built my first product based on a custom
> > python class I wrote (its a router object that has methods to query
> > various snmp oids) based on a ZClass and I want to make sure that I am
> > not doing anything wrong.
> > In addition to the methods that query the oids, I store the results in
> > an instance variable of my Python class so I can cache the information
> > for a specified amount of time.  Is this safe to do?  Can I store
> > these values in my Python instance (self.xxxx), not a ZClass property?
> 
> Sure, just make sure you abide by the stuff above.
> 
> > Also, What happens if multiple people activate my query method, do I
> > need to worry about them stomping over each other as the method writes
> > the results to the instance variables?  Is there any record locking of
> > objects?
> 
> The ZODB will flag a ConflictError and will cause the second attempter
> to retry.  This is pretty normal, and your data won't get munged.  Look
> out, however, if you're really concerned, about "hot spots" that can
> effect performance.
>  
> > Lastly, since I couldn't really find any pointers regarding a builtin
> > Zope scheduler that is bug free, I need to write a small python script
> > that I can place in a cron job to run every ten minutes to call the
> > query methods of these objects so they update their cache instances.
> > Is there a link on how to get a regular Python script access to the
> > ZODB?
> 
> Yes... sort of.  Try looking for a HowTo named "The Debugger is Your
> Friend" by Michel Pelletier.  That shows you how to use the Zope module
> from inside python.  It's simpler than you might expect.  Here's an
> example (make sure you shut down your Zope before you try this or it
> won't work):
> 
> [chrism@opar chrism]$ cd Zope2.1.6/lib/python
> [chrism@opar chrism]$ python
> >>> import Zope
> >>> app = Zope.app()
> >>> app
> <Application instance at 8455220>
> >>> dir(app)
> ['Control_Panel', '__allow_groups__'........]
> 
> Play around inside Python, call methods on things, etc.  This is a great
> way to learn more about Zope.
>  
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
> 

-- 
Peter Kazmier                                 http://www.kazmier.com
PGP Fingerprint   4FE7 8DA3 D0B5 9CAA 69DC  7243 1855 BC2E 4B43 5654