durusmail: durus-users: changes in the first client not available in the second client
changes in the first client not available in the second client
2004-07-26
2004-07-26
changes in the first client not available in the second client
Jon Dyte
2004-07-26
Hi Ludo
in another email Neil explained to me that you have issue
connection.commit() or connection.abort() in the second client. If you do that
it works.

seems abort() is like ZODB's sync

cheers

Jon

On Monday 26 July 2004 14:11, Ludovico Magnocavallo wrote:
> Running the Quick Demo as suggested in the README, I notice that changes
> in the first client are not available in the second client:
>
> --- first client ---
> /-(ludo@ludo)-(69/pts)-(15:03:42:Mon Jul 26)--
> \-($:~)-- client.py
> Durus (127.0.0.1:2972)
>      connection -> the connection
>      root       -> get(0)
>      get(oid)   -> get an object
>      pp(object) -> pretty-print
>
>  >>> root.keys()
>
> []
>
>  >>> root['pippo'] = 1
>  >>> root.keys()
>
> ['pippo']
>
>  >>> connection.commit()
>  >>> root.keys()
>
> ['pippo']
>
>
> --- second client (server in the background on the same console) ---
>
> /-(ludo@ludo)-(16/pts)-(15:04:15:Mon Jul 26)--
> \-($:~)-- client.py
> Committed   1 objects 77 bytes
> Durus (127.0.0.1:2972)
>      connection -> the connection
>      root       -> get(0)
>      get(oid)   -> get an object
>      pp(object) -> pretty-print
>
>  >>> root.keys()
>
> []
>
>  >>> Committed   1 objects 89 bytes
>  >>>
>  >>> root.keys()
>
> []
>
>  >>> root.keys()
>
> []
>
>  >>> root.keys()
>
> []
>
>
> ----------
>
> Is this normal? Do I have to call any connection method in the second
> client to see the committed objects?
>
> Thanks
>
> Ludo
> _______________________________________________
> Durus-users mailing list
> Durus-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/durus-users


reply