modeling-users

[Modeling-users] EditingContext and Zope Sessions

[frobni b. <fro...@ya...>]

Hello,

According to the documentation
ZEditingContextSessioning allows to lazily create an
EditingContext on a per-session basis.

Is it possible to somehow (automatically) bind the
EditingContext to a Zope Transaction (e.g. a Web
Request).

What is the advantage of binding the EditingContext to
a Session instead of a transaction? - e.g. Zope SQL
Methods commit the (SQL) Transaction on the end of the
Zope Transaction and I never had any problems with
them.

thanx


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Modeling-users] EditingContext and Zope Sessions

[Sebastien B. <sbi...@us...>]

        Hi,

frobni barka <fro...@ya...> wrote:
> Hello,
>=20
> According to the documentation
> ZEditingContextSessioning allows to lazily create an
> EditingContext on a per-session basis.
>=20
> Is it possible to somehow (automatically) bind the
> EditingContext to a Zope Transaction (e.g. a Web
> Request).

Yes it is --see below.

> What is the advantage of binding the EditingContext to
> a Session instead of a transaction? - e.g. Zope SQL
> Methods commit the (SQL) Transaction on the end of the
> Zope Transaction and I never had any problems with
> them.

  The EC is delivered as part of the session. This allows you to decide
  where you want to save the changes. This may --or may not-- be at the
  end of a zope transaction. A typical situation where both are
  decorrelated is when you needs two (html/zope) pages or more to make
  changes.=20

With an example this is clearer: suppose you have an address book
application, and that Persons objects must have an valid Address (i.e.
the relationship between Person and Address is mandatory). Suppose now
that you want to have one page for filling the person's properties
(first & last name, etc.), then a second one to fill his/her address
fields.

  Page 1: Person -> validate -> Page 2: Address -> validate -> save changes

Here you don't want to save your changes when page 1 validates its
changes (this is the end of a zope transaction), but after page 2
validates. Hence, in this case, you'll design your product to
saveChanges() when page 2 is validated. Moreover, if you send a
saveChanges() when page 1 validates, you'll get an error, because the
person inserted in the EC has no address while this is required by the
model: the EC won't let you save objects in an inconsistent state.

  Back to your problem now: what you're asking for is not in-the-box,
  because I never needed it :) I've quickly made a patch that you'll
  find at the end of the message, which enables automatic saveChanges().

Apply it to ZEditingContextSessioning/__init__.py

   patch -p0 < __init__.py.patch

and then all your SESSION.defaultEditingContext() will saveChanges()
when a zope transaction ends (just like ZSQL methods do).

  I'd be glad to hear from you if you use it successfully --I'll then
  probably add this as an option in the product itself.

        Regards,

-- S=E9bastien.


Here is the patch __init__.py.patch:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/modeling/ZModeling/ZEditingContextSessioning/__init__.py=
,v
retrieving revision 1.3
diff -u -r1.3 __init__.py
--- __init__.py 22 Apr 2003 09:36:50 -0000      1.3
+++ __init__.py 31 Aug 2003 22:52:33 -0000
@@ -36,6 +36,31 @@
 from Products.Transience.TransientObject import TransientObject
 import zLOG
=20
+from Shared.DC.ZRDB.TM import TM
+class ECProxy(TM):
+  def __init__(self, ec):
+    zLOG.LOG("ECProxy", zLOG.INFO, '__init__')
+    self.ec=3Dec
+    self._register()
+=20=20=20=20
+  def _abort(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_abort')
+    pass
+
+  def _finish(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_finish')
+    self.ec.saveChanges()
+
+  def _begin(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_begin')
+    pass
+
+  def __getattr__(self, n):
+    zLOG.LOG("ECProxy", zLOG.INFO, "__getattr__")
+    if hasattr(self.ec, n):
+      return getattr(self.ec, n)
+    raise ValueError
+=20=20
 ## Implementation note:
 ## session.token was formerly used instead of session.id
 ## --> BAD IDEA
@@ -64,7 +89,8 @@
   """
   Returns the EditingContext bound to 'session'
   """
-  return EditingContextSessioning.getEditingContext(session.id)
+  zLOG.LOG("Products.ZEditingContextSessioning", zLOG.DEBUG, 'defaultEC()')
+  return ECProxy(EditingContextSessioning.getEditingContext(session.id))
=20
=20
 def initialize(context):

Re: [Modeling-users] EditingContext and Zope Sessions

[Sebastien B. <sbi...@us...>]

        Hi,

  I worked a bit on the previously posted patch, the ability to bind mdl
  txns to zope txns is now controlled by a special property of the
  product. See the patch at:

https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D801961&group_=
id=3D58935&atid=3D489337

This patch allows you to bind the sessions' defaultEditingContext() to
the zope transaction mechanism.

  If the boolean property of the Product ZEditingContext (accessible at
  Control_Panel/Products/ZEditingContextSessioning/manage_propertiesForm)
  'bind_saveChanges_to_zope_transactions' is set, saveChanges() is
  called on the session's defaultEditingContext() each time a zope
  request/txn ends.

NB: this has already been applied to CVS and will be in the next
release.

        Regards,

-- S=E9bastien.


frobni barka <fro...@ya...> wrote:
> Hello,
>=20
> According to the documentation
> ZEditingContextSessioning allows to lazily create an
> EditingContext on a per-session basis.
>=20
> Is it possible to somehow (automatically) bind the
> EditingContext to a Zope Transaction (e.g. a Web
> Request).

Re: [Modeling-users] EditingContext and Zope Sessions

[frobni b. <fro...@ya...>]

Thanks a lot.

I have another question concerning the sample code at
the main page.

john.addToAddresses(a_john); a_john.setPerson(john)

Wouldn't it be enough to just use one of the above
statements, because they do the same thing?

--- Sebastien Bigaret <sbi...@us...>
wrote:
> 
>         Hi,
> 
>   I worked a bit on the previously posted patch, the
> ability to bind mdl
>   txns to zope txns is now controlled by a special
> property of the
>   product. See the patch at:
> 
>
https://sourceforge.net/tracker/index.php?func=detail&aid=801961&group_id=58935&atid=489337
> 
> This patch allows you to bind the sessions'
> defaultEditingContext() to
> the zope transaction mechanism.
> 
>   If the boolean property of the Product
> ZEditingContext (accessible at
>  
>
Control_Panel/Products/ZEditingContextSessioning/manage_propertiesForm)
>   'bind_saveChanges_to_zope_transactions' is set,
> saveChanges() is
>   called on the session's defaultEditingContext()
> each time a zope
>   request/txn ends.
> 
> NB: this has already been applied to CVS and will be
> in the next
> release.
> 
>         Regards,
> 
> -- Sébastien.
> 
> 
> frobni barka <fro...@ya...> wrote:
> > Hello,
> > 
> > According to the documentation
> > ZEditingContextSessioning allows to lazily create
> an
> > EditingContext on a per-session basis.
> > 
> > Is it possible to somehow (automatically) bind the
> > EditingContext to a Zope Transaction (e.g. a Web
> > Request).
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Modeling-users] EditingContext and Zope Sessions

[Sebastien B. <sbi...@us...>]

        Hi,

frobni barka <fro...@ya...> wrote:
> I have another question concerning the sample code at
> the main page.
>=20
> john.addToAddresses(a_john); a_john.setPerson(john)
>=20
> Wouldn't it be enough to just use one of the above
> statements, because they do the same thing?


No, it would not be enough, let's see why.

  As a general rule, the graph of objects hold by an EditingContext
  should be kept consistent. As the association is bi-directional in the
  PyModel exposed on the first page, both objects should be modified
  with the relevant informations.

This has nothing to do with RDBMS: imagine you just write:

>>> address_john.setPerson(john)

  This does not update 'john' itself, and its list of addresses will not
  contain the new addresses, that's why you also need to update the
  other side. They do not really /do/ the same thing, but they both
  participate in updating the association. In fact, that has little to
  do with the framework, except that the framework expects the graph of
  objects to be consistent --or it could make wrong decisions, in this
  case, it might incorrectly analyse the changes that have been made and
  as a consequence, not save the modifications as expected.

Now, every object in the framework inherits from CustomObject which has
a mix-in named 'RelationshipManipulation' that can ease the way you
update the relationships. It uses the model to determine what should be
done when you modify a relationship; for example,

>>> john.addObjectToBothSidesOfRelationshipWithKey(a_john, 'addresses')

  will update john and a_john in the same time. Moreover, imagine a_john
  was previously bound to john2, it will also remove a_john from john2's
  list of address. This is a convenient method, I think, that can be of
  some help. For further details about this, please see section 8.1 in
  the User's Guide:
http://modeling.sf.net/UserGuide/customobject-relationshipmanipulation.html


        Regards,

-- S=E9bastien.

[Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Ernesto R. <er...@si...>]

Hi,

just a little note if this issue haven't arosen yet.

I've standalone ZODB 3.1.1 installed, running under Python 2.2 / Win32.

When I do a=20
from Modeling.PyModel import *

I get the following error:
  File "<stdin>", line 1, in ?
  File "c:\prg\python22\Lib\site-packages\Modeling\PyModel.py", line 57, =
in ?
    from Entity import externalNameForInternalName
  File "c:\prg\python22\Lib\site-packages\Modeling\Entity.py", line =
1442, in ?
    finalize_docstrings(Entity, ENTITY_DOC)
  File "c:\prg\python22\Lib\site-packages\Modeling\utils.py", line 166, =
in finalize_docstrings
    for n,m in inspect.getmembers(klass, inspect.ismethod):
  File "c:\prg\python22\lib\inspect.py", line 161, in getmembers
    value =3D getattr(obj, key)
AttributeError: __call__

In Entity.py, Entity  will now be a extension class, because of =
Persistent (which is cPersistence.Persistent) and dir exposes an =
attribute __call__, that when doing a getattr(Entity,'__call__') fails =
in inspect.getmembers, inside the Python standard lib.

To circumvate this I put a quick and dirty:
raise 'Don't use ZODB'=20

near line 113 of Entity.py, in order to avoid ZODB Persistence =
mechanism. Perhaps, this is a bug in Python 2.2 because:
>>> import ZODB
>>> from Persistence import Persistent
>>> dir(Persistent)
['__basicnew__', '__call__', '__changed__', '__delattr__', '__doc__', =
'__getattr__', '__getstate__', '__init__', '__module__', '__reduce__', =
'__repr__', '__setattr__', '__setstate__', '_p_deactivate', =
'inheritedAttribute']
>>> getattr(Persistent,'__call__')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
AttributeError: __call__
>>>

I'll try Python 2.2.3 and tell you if the error persist.

Erny

Re: [Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Sebastien B. <sbi...@us...>]

        Hi Erny,

  Oh my, I think this bug was already reported quite a long time ago by
Soaf, and I completely forgot about it. You can safely comment the last
line of Entity.py: finalize_docstrings() is absolutely useless wrt the
runtime, it only updates some docstrings with a common pattern. I made
this when investigating some methods to share documentation in
docstrings, but this is definitely not the way to do this, and it
shouldn't have been integrated into the main trunk.

  I'll remove this in the next release. Thanks a lot for reporting, and
  sorry for the inconvenience.

-- S=E9bastien.

PS: BTW, Entity, Model, etc. inherits from ZODB.Persistent because of
    the ZModeler, which uses them as-is; this allows them to remain
    persistent in a zope instance, so you don't want to disable this if
    you use the ZModeler.


"Ernesto Revilla" <er...@si...> wrote:
> Hi,
> just a little note if this issue haven't arosen yet.
>=20
> I've standalone ZODB 3.1.1 installed, running under Python 2.2 / Win32.
>=20
> When I do a=20
> from Modeling.PyModel import *
>=20
> I get the following error:
>   File "<stdin>", line 1, in ?
>   File "c:\prg\python22\Lib\site-packages\Modeling\PyModel.py", line 57, =
in ?
>     from Entity import externalNameForInternalName
>   File "c:\prg\python22\Lib\site-packages\Modeling\Entity.py", line 1442,=
 in ?
>     finalize_docstrings(Entity, ENTITY_DOC)
>   File "c:\prg\python22\Lib\site-packages\Modeling\utils.py", line 166, i=
n finalize_docstrings
>     for n,m in inspect.getmembers(klass, inspect.ismethod):
>   File "c:\prg\python22\lib\inspect.py", line 161, in getmembers
>     value =3D getattr(obj, key)
> AttributeError: __call__
>=20
> In Entity.py, Entity  will now be a extension class, because of Persisten=
t (which is cPersistence.Persistent) and dir exposes an attribute __call__,=
 that when doing a getattr(Entity,'__call__') fails in inspect.getmembers, =
inside the Python standard lib.
>=20
> To circumvate this I put a quick and dirty:
> raise 'Don't use ZODB'=20
>=20
> near line 113 of Entity.py, in order to avoid ZODB Persistence mechanism.=
 Perhaps, this is a bug in Python 2.2 because:
> >>> import ZODB
> >>> from Persistence import Persistent
> >>> dir(Persistent)
> ['__basicnew__', '__call__', '__changed__', '__delattr__', '__doc__', '__=
getattr__', '__getstate__', '__init__', '__module__', '__reduce__', '__repr=
__', '__setattr__', '__setstate__', '_p_deactivate', 'inheritedAttribute']
> >>> getattr(Persistent,'__call__')
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> AttributeError: __call__
> >>>
>=20
> I'll try Python 2.2.3 and tell you if the error persist.
>=20
> Erny

Re: [Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Ernesto R. <er...@si...>]

Hi again,

what is the consequence of having ZODB standalone installed when using =
Modeling? Are there any important differences between =
Persistence.Persistent and Persistent.Persistent?

regards,
Erny


----- Original Message -----=20
From: "Sebastien Bigaret" <sbi...@us...>
To: "Ernesto Revilla" <er...@si...>
Cc: "modeling-users" <mod...@li...>
Sent: Tuesday, September 16, 2003 10:34 PM
Subject: Re: [Modeling-users] Problems importing Modeling with ZODB =
3.1.1 installed



        Hi Erny,

  Oh my, I think this bug was already reported quite a long time ago by
Soaf, and I completely forgot about it. You can safely comment the last
line of Entity.py: finalize_docstrings() is absolutely useless wrt the
runtime, it only updates some docstrings with a common pattern. I made
this when investigating some methods to share documentation in
docstrings, but this is definitely not the way to do this, and it
shouldn't have been integrated into the main trunk.

  I'll remove this in the next release. Thanks a lot for reporting, and
  sorry for the inconvenience.

-- S=E9bastien.

PS: BTW, Entity, Model, etc. inherits from ZODB.Persistent because of
    the ZModeler, which uses them as-is; this allows them to remain
    persistent in a zope instance, so you don't want to disable this if
    you use the ZModeler.


"Ernesto Revilla" <er...@si...> wrote:
> Hi,
> just a little note if this issue haven't arosen yet.
>=20
> I've standalone ZODB 3.1.1 installed, running under Python 2.2 / =
Win32.
>=20
> When I do a=20
> from Modeling.PyModel import *
>=20
> I get the following error:
>   File "<stdin>", line 1, in ?
>   File "c:\prg\python22\Lib\site-packages\Modeling\PyModel.py", line =
57, in ?
>     from Entity import externalNameForInternalName
>   File "c:\prg\python22\Lib\site-packages\Modeling\Entity.py", line =
1442, in ?
>     finalize_docstrings(Entity, ENTITY_DOC)
>   File "c:\prg\python22\Lib\site-packages\Modeling\utils.py", line =
166, in finalize_docstrings
>     for n,m in inspect.getmembers(klass, inspect.ismethod):
>   File "c:\prg\python22\lib\inspect.py", line 161, in getmembers
>     value =3D getattr(obj, key)
> AttributeError: __call__
>=20
> In Entity.py, Entity  will now be a extension class, because of =
Persistent (which is cPersistence.Persistent) and dir exposes an =
attribute __call__, that when doing a getattr(Entity,'__call__') fails =
in inspect.getmembers, inside the Python standard lib.
>=20
> To circumvate this I put a quick and dirty:
> raise 'Don't use ZODB'=20
>=20
> near line 113 of Entity.py, in order to avoid ZODB Persistence =
mechanism. Perhaps, this is a bug in Python 2.2 because:
> >>> import ZODB
> >>> from Persistence import Persistent
> >>> dir(Persistent)
> ['__basicnew__', '__call__', '__changed__', '__delattr__', '__doc__', =
'__getattr__', '__getstate__', '__init__', '__module__', '__reduce__', =
'__repr__', '__setattr__', '__setstate__', '_p_deactivate', =
'inheritedAttribute']
> >>> getattr(Persistent,'__call__')
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> AttributeError: __call__
> >>>
>=20
> I'll try Python 2.2.3 and tell you if the error persist.
>=20
> Erny

Re: [Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Jerome K. (soaf) <so...@la...>]

On Wednesday 17 September 2003 00:17, Ernesto Revilla wrote:
> Hi again,
>
> what is the consequence of having ZODB standalone installed when using
> Modeling? Are there any important differences between
> Persistence.Persistent and Persistent.Persistent?
>
> regards,
> Erny

I have never tested this kind of stuff. but i really think that doesn't 
matter. as I Persistence is only used by the ZModeler ( as it is 
a normal zope object ). Perhaps this can change something
when you bind the editing context with Zope session. But i 
don't like think . (And i haven't read / test this code) 

Are you using only ZModeler ? or all Modeling inside Zope ? 



Bye Bye..  

Re: [Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Ernesto R. <er...@si...>]

----- Original Message -----=20
From: "Jerome Kerdreux (soaf)" <so...@la...>
>=20
> Are you using only ZModeler ? or all Modeling inside Zope ?=20
Actually Modeling is outside of Zope. But the final scenario isn't still =
clear for me. We'll do XML-RPC access from client software (also written =
in Python), so Zope is an attractive solution, as it unifies Web access =
and other client access to the data.

Erny

Re: [Modeling-users] Problems importing Modeling with ZODB 3.1.1 installed

[Sebastien B. <sbi...@us...>]

"Jerome Kerdreux (soaf)" <so...@la...> wrote:
> On Wednesday 17 September 2003 00:17, Ernesto Revilla wrote:
> > Hi again,
> >
> > what is the consequence of having ZODB standalone installed when using
> > Modeling? Are there any important differences between
> > Persistence.Persistent and Persistent.Persistent?
> >
> > regards,
> > Erny
>=20
> I have never tested this kind of stuff. but i really think that doesn't=20
> matter. as I Persistence is only used by the ZModeler ( as it is=20
> a normal zope object ). Perhaps this can change something
> when you bind the editing context with Zope session. But i=20
> don't like think . (And i haven't read / test this code)=20

Soaf is right, there's not consequences on the runtime, it's only there to
make model, entities, etc. persistent in a zope/zmodeler instance.

  To convince yourself, look at Modeling.Persistent.Persistent ;))
        class Persistent:
          pass


-- S=E9bastien.