[Zope-dev] Storing references in objects accross requests - bad or OK?

2004-06-13 Thread Dario Lopez-Kästen
hello,
I am am worrying a problem here, where I need to store references to 
objects in my own objects, while at the same time needing to store and 
retreive my objects later.

Here is an example of what I need to do:
in a product BooTool for Zope I have:

class Foo:
  def __init__(self, data, ref_a):
self.data = data
self.a_handle = ref_a
self.stuff = []
  def bar(self):
# do something with self.stuff
cool = self.a_handle('one')
self.stuff.append(cool)
return self.stuff
def getStuff(data, ref_a):
   his method is available to Zope from the tool boo_tool 
  return Foo(data, ref_a)

in a python script I have a pythonscript:

my_ob = context.boo_tool.getStuff('123', container.my_script)
return my_ob

so my_ob contains a reference to the my_script Pythonscript/ZSQL Method.
What happens if I store my_ob in a session storage for instance and 
later retrieve it and do my_ob.bar() ?

What bad things can happen?
Thanks for any input.
/dario
--
-- ---
Dario Lopez-Kästen, IT Systems  Services Chalmers University of Tech.
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Storing references in objects accross requests - bad or OK?

2004-06-13 Thread Dieter Maurer
Dario Lopez-Kästen wrote at 2004-6-13 12:43 +0200:
I am am worrying a problem here, where I need to store references to 
objects in my own objects, while at the same time needing to store and 
retreive my objects later.

Your problem can be summarized by storing acquisition wrappers
(of persistent objects) across requests.

This is very difficult!
You have a very good chance to get burned.

You cannot store them in the ZODB as acquisition wrappers cannot
be stored there. Currently, the ZODB silently unmantles
acquisition wrappers. They may be rebound on access -- but
this will not give you the original acquisition context and
behaviour can be drastically different.

You cannot store them via module global data structures
as the values (indirectly) reference persitent objects.
You must never put persistent objects outside the scope of its ZODB
connection as this will give nasty (non deterministic) persistency bugs.

You could store such values as volatile attributes (_v_)
of persistent objects. However, volatile attributes
are not completely reliable (as the name suggests).
And they are (ZODB) connection local -- another connection does not
see them.

You may put such objects into attributes of the ZODB connection
itself. Again, they will be connection local.


Urgent recommendation: avoid storing acquisition wrapped objects
across requests, store paths instead and locate the objects by
means of the paths.

-- 
Dieter

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


[Zope-dev] re:cc:Home delívery on all meds.

2004-06-13 Thread Lenard Westbrook








   bernice prejudice cetus done gubernatorial cyclorama traceable corrugate blast inaudible oaken ethic philharmonic repairmen iceberg beacon accordion compilation anvil chronicle gully lyle perseverance conqueror ouzo president lockstep quint extricable gloomy foodstuff copperhead razor redwood bestubble cavern zealand darrell medicine jorgenson  bratwurst amino stank bugeyed nightclub beauteous restorative determinant dribble convertible arroyo intersperse bonze euterpe macdonald perilla sonic berlin variety umber swenson substituent assess segovia madman vida convect catchy rat taverna macmillan insurgent jean coordinate tuna vaughn  quizzical isothermal restroom gladys ghost olivine bugging histamine richmond kaplan profundity boundary boyle histamine pitman shorten bagel parson muscovy therapeutic twit watchman quonset birgit bankrupt checkerboard chippendale schlitz raven leslie atchison orthodontic ephesus footwear  workspace drift aggravate lorinda empiric demountable gorky arpa reliant ak osborne tornado dry closet uptown federate stodgy silverman trianon puny quintillion spoke  bradbury acetylene divorcee gridiron shoemake genesis pembroke handel sari drop consulate aphelion jot insolvent abject alimony crump dirge bartok bronx foible alleyway bonnie ostensible pta suppression suntan taper braniff erotic belie chart  cam larry plot marietta bremen duress ironwood perspective fiery polarogram yeomanry disjunct compulsory convertible chastise macrophage deuterium bluestocking dummy christine echoes cove matthews airtight adolph macho olaf rebut borate crabmeat russo presumption compete waterway jumble vacuole bradshaw calorimeter pablo bayonne  chimeric rotary pinion resemblant bauer avocate tonsillitis masque none push contemplate pierre atrophy  pinafore lurid shrive aggression desmond scanty albanian bustard frog mussel convair olden demurrer cute dispersive nestle ascribe swoop alcohol preemption inhere passage shrewd checkmate lynch disneyland desperado regime remainder clothesmen department czarina nebraska aventine remark configure armenia bechtel accompany 
   
 ridme 


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