[Zope-dev] Reg. persisting data in ZODB via forms
Hello all, I am using zope.formlib.form package for my forms, when overriding the 'createAndAdd' method of form.AddForm I don't explicitly do the zope.event.notify(ObjectCreatedEvent(..)) call. I just add the data to self.context and it gets added (persisted) in the ZODB. But when I extend the form.EditForm in order to implement my own Apply action method, just calling the form.applyData or form.applyChanges doesn't persist the data. zope.event.notify(ObjectModifiedEvent(..)) call is needed in order to persist data. If someone could explain on this or point me to some documentation relating to this would be very helpful to me. Thank you Regards -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joshua, Am 08.06.2011, 10:34 Uhr, schrieb Joshua Immanuel j...@hipro.co.in: Hello all, I am using zope.formlib.form package for my forms, when overriding the 'createAndAdd' method of form.AddForm I don't explicitly do the zope.event.notify(ObjectCreatedEvent(..)) call. I just add the data to self.context and it gets added (persisted) in the ZODB. Persistence is handled by the transaction management and is IIRC independent of the notifications system. Nevertheless, not calling the events is not advisable. But when I extend the form.EditForm in order to implement my own Apply action method, just calling the form.applyData or form.applyChanges doesn't persist the data. zope.event.notify(ObjectModifiedEvent(..)) call is needed in order to persist data. If someone could explain on this or point me to some documentation relating to this would be very helpful to me. From memory I can recall something similar related to making changes to copies of instance attributes but failing to apply them to attributes and needing to specifically go context.attribute = form_result for the changes to persist. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hello Charlie,
On Wed, 2011-06-08 at 10:48 +0200, Charlie Clark wrote:
From memory I can recall something similar related to making changes
to copies of instance attributes but failing to apply them to
attributes and needing to specifically go context.attribute =
form_result for the changes to persist.
Supposing, we have a form action like:
@form.action('Apply')
def handle_edit(self, action, data):
self.context.name += Blah
This change is visible in subsequent requests. i.e if we view this
object via another form, we can see the modification. However, if we
restart the server (bluebream), this change is lost. The same thing
happens when we use form.applyData. If we 'notify'
ObjectModifiedEvent, this does not happen.
Since the object's modification is visible across requests, I am
assuming that the transaction mechanism 'did' apply the changes to the
object.
But, it did not get to the disk :-/
--
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in/
signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joe,
Am 08.06.2011, 11:05 Uhr, schrieb Joe Steeve j...@hipro.co.in:
Supposing, we have a form action like:
@form.action('Apply')
def handle_edit(self, action, data):
self.context.name += Blah
This change is visible in subsequent requests. i.e if we view this
object via another form, we can see the modification. However, if we
restart the server (bluebream), this change is lost. The same thing
happens when we use form.applyData. If we 'notify'
ObjectModifiedEvent, this does not happen.
Since the object's modification is visible across requests, I am
assuming that the transaction mechanism 'did' apply the changes to the
object.
But, it did not get to the disk :-/
I'm surprised at this but I'm not familiar with Bluebream's transactional
processing. The quickest thing to do is to reenable notification and add a
debug so that you can follow all the subscription calls and see what you
need to call.
Why do want to disable notification?
Charlie
--
Charlie Clark
Managing Director
Clark Consulting Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hello Charlie, On Wed, 2011-06-08 at 11:16 +0200, Charlie Clark wrote: I'm surprised at this but I'm not familiar with Bluebream's transactional processing. The quickest thing to do is to reenable notification and add a debug so that you can follow all the subscription calls and see what you need to call. How do we get the list of subscribers for a particular event? Why do want to disable notification? We dont want to disable notification. We are just trying to understand how zope.formlib works. We were of the understanding that every 'request' starts and ends a transaction automatically (somewhere). So, seeing this explicit notify() confused us. Note that adding a new object does not require this explicit notify(). Further, if we have to expect the developer to manually notify after every change, it could invite unnecessary bugs. We are killing the server with a Ctrl-C. Maybe something is not getting flushed out to the disk yet? -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On Wed, 2011-06-08 at 15:01 +0530, Joe Steeve wrote: We are killing the server with a Ctrl-C. Maybe something is not getting flushed out to the disk yet? Tried this with --daemon and --stop-daemon to paster. Still no change. So, this is not an issue. -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Am 08.06.2011, 11:31 Uhr, schrieb Joe Steeve j...@hipro.co.in: How do we get the list of subscribers for a particular event? By checking the registry for all adapters registered. from zope.component import queryAdapter queryAdapter(object, interface) ... # check the syntax and make sure you have the registry loaded. Why do want to disable notification? We dont want to disable notification. We are just trying to understand how zope.formlib works. We were of the understanding that every 'request' starts and ends a transaction automatically (somewhere). So, seeing this explicit notify() confused us. Note that adding a new object does not require this explicit notify(). The transactional stuff does not happen in zope.formlib. Unfortunately zope.formlib is a bit opaque in the way it works. Further, if we have to expect the developer to manually notify after every change, it could invite unnecessary bugs. Which is why you should let the library handle this for you wherever possible and something you write tests for. We are killing the server with a Ctrl-C. Maybe something is not getting flushed out to the disk yet? No, that is not likely to be the case. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Transaction successful, but changes not pushed to disk (was) Reg. persisting data in ZODB via forms
On Wed, 2011-06-08 at 11:40 +0200, Charlie Clark wrote: Further, if we have to expect the developer to manually notify after every change, it could invite unnecessary bugs. Which is why you should let the library handle this for you wherever possible and something you write tests for. The problem is when we have to add multiple actions to a form, and each of them modify the object in different ways (say). In such a case, we cannot use the form.EditForm as is. We need to add more actions explicitly. And, if we have to notify(IObjectModifiedEvent) everytime, for the object to be persisted, it does not seem nice. I would have been happy if the transaction failed completely. But, it had not. The transaction was successful. Subsequent requests on the same object show that the previous modifications are intact. The object's changes just did not make it to the disk. -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Transaction successful, but changes not pushed to disk (was) Reg. persisting data in ZODB via forms
On Wed, 2011-06-08 at 15:23 +0530, Joe Steeve wrote: I would have been happy if the transaction failed completely. But, it had not. The transaction was successful. Subsequent requests on the same object show that the previous modifications are intact. The object's changes just did not make it to the disk. Found the issue. The problem was with our code. The content class was not derived from persistent.Persistent. Fixing that fixed the problem. Thanks guys :) -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 9, OK: 72
On 6/6/11 16:48 , Tres Seaver wrote: On 06/05/2011 02:24 PM, Hanno Schlichting wrote: On Sun, Jun 5, 2011 at 6:31 PM, Tres Seaver tsea...@palladion.com wrote: [1]FAILED Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2011-June/042535.html [2]FAILED Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2011-June/042537.html These two are both the segfault-at-exit issue. I finally took the time to install me a virtual machine with Ubuntu 64bit on it. And I was able to reproduce the issue! It's not a segfault at exit, but actually happens inside a test: test_interfaces (Acquisition.tests) (0.001 s) test_mixed_explicit_and_explicit (Acquisition.tests)Segmentation fault Or to get the issue quicker: $ bin/alltests -s Acquisition -t test_mixed_explicit_and_explicit Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Segmentation fault I haven't yet tried to debug the problem itself. I cannot reproduce on my native Ubuntu x86_64 machine using a built-from-scratch Python 2.7.1:: On the specific buildslave machine I tested with a python-2.7 built from scratch, re-ran bootstrap.py, bin/buildout, bin/alltests and all tests passed. It seems the python-2.7 from the deadsnakes PPA that is installed on this buildmachine behaves badly. I do not know why, and I do not really feel like investigating it. I'll remove the python-2.7 PPA install from this machine we'll start using the hand-build python-2.7 instead. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On 8 June 2011 10:05, Joe Steeve j...@hipro.co.in wrote:
Hello Charlie,
On Wed, 2011-06-08 at 10:48 +0200, Charlie Clark wrote:
From memory I can recall something similar related to making changes
to copies of instance attributes but failing to apply them to
attributes and needing to specifically go context.attribute =
form_result for the changes to persist.
Supposing, we have a form action like:
@form.action('Apply')
def handle_edit(self, action, data):
self.context.name += Blah
This change is visible in subsequent requests. i.e if we view this
object via another form, we can see the modification. However, if we
restart the server (bluebream), this change is lost. The same thing
happens when we use form.applyData. If we 'notify'
ObjectModifiedEvent, this does not happen.
Since the object's modification is visible across requests, I am
assuming that the transaction mechanism 'did' apply the changes to the
object.
But, it did not get to the disk :-/
This looks like self.context is not an instance of a Persistent
subclass. Only Persistent subclasses know how to register their
changes with the ZODB. You see the change on subsequent requests
because the object remains in the object cache, as soon as it's parent
Persistent instance is invalidated, or the server restarted the
changes will disappear. Storing mutable non-persistent objects in the
ZODB requires some care, specifically you need to register the change
on the object's persistent parent. The easiest way to do this is to
assign it to the parent again, e.g. parent['child-name'] = child.
My guess is that the ObjectModifiedEvent is dispatched to your
object's parent and causes something to change there, with the side
effect of storing your updated object.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 17, OK: 91
2011/5/25 Gediminas Paulauskas mene...@pov.lt:
2011/5/25 Marius Gedminas mar...@gedmin.as:
On Wed, May 25, 2011 at 09:18:46AM -0400, Tres Seaver wrote:
[3] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx
https://mail.zope.org/pipermail/zope-tests/2011-May/041867.html
The is an FTP test failure, similar to others which have showed up::
-- $ -
Failure in test testHELP (zope.server.ftp.tests.test_ftpserver.Tests)
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/unittest.py,
line 260, in run
testMethod()
File
/Users/buildslave/.buildout/eggs/zope.server-3.6.2-py2.5.egg/zope/server/ftp/tests/test_ftpserver.py,
line 278, in testHELP
self.assertEqual(self.execute('HELP', 1), result)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/unittest.py,
line 334, in failUnlessEqual
(msg or '%r != %r' % (first, second))
AssertionError: '214-The following commands are recognized\r\n' !=
'214-The following commands are recognized\r\nHelp goes here
somewhen.\r\n214 Help done.\r\n'
-- $ -
I have no idea why this failure is only occasionaly, and only on OS/X.
I had a theory and proposed a possible fix a while ago, but had no way
of testing it:
https://mail.zope.org/pipermail/zope-dev/2010-December/042138.html
I have tested this and committed an equivalent patch:
http://zope3.pov.lt/trac/changeset/121089/zope.server/trunk
This was released recently as zope.server 3.8.3 (that has a new test
failing on Python 2.6)
I have released the fix for Python 2.6 as 3.8.4.
Have to backport to 3.6 branch for ZTK 1.0... and make new bugfix release
Branch created, minor fixes backported, including this testHELP
failure, and released as 3.6.3:
http://zope3.pov.lt/trac/log/zope.server/branches/3.6
--
Gediminas
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
As I mentioned on a follow-up post, we figured the 'Persistent' part. :) On Wed, 2011-06-08 at 13:29 +0100, Laurence Rowe wrote: My guess is that the ObjectModifiedEvent is dispatched to your object's parent and causes something to change there, with the side effect of storing your updated object. Even if the object's parent (a btree-container) had changed, will it attempt to force-store its entire child-tree? I am trying to imagine the effect of it on a huge tree. -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 8, OK: 67
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [8]FAILED winbot / ztk_10 py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-June/042814.html Network timeout in bootstrap, trying to find the zc.buildout egg. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3vffIACgkQ+gerLs4ltQ5zogCgjFq5/mj7eI506TfbojNurEMM 7+4Amwf66UlniwdDLbwCRyHmmWiirEa1 =Dqow -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On Wed, Jun 08, 2011 at 06:20:26PM +0530, Joe Steeve wrote: As I mentioned on a follow-up post, we figured the 'Persistent' part. :) On Wed, 2011-06-08 at 13:29 +0100, Laurence Rowe wrote: My guess is that the ObjectModifiedEvent is dispatched to your object's parent and causes something to change there, with the side effect of storing your updated object. Even if the object's parent (a btree-container) had changed, will it attempt to force-store its entire child-tree? I am trying to imagine the effect of it on a huge tree. The smallest unit that is ever written to a ZODB is one persistent object (with all its nonpersistent attributes/items, recursively). BTrees use multiple persistent buckets for their state and are very efficient, storage-wise. But this only matters when you're adding/removing items to a BTree. If you're modifying a persistent object stored in a BTree, the BTree itself remains unmodified and does not need to be re-written Marius Gedminas -- Linux became only possible because 20 years of OS research was carefully studied, analyzed, discussed and thrown away. -- Ingo Molnar signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/08/2011 01:40 PM, Marius Gedminas wrote: On Wed, Jun 08, 2011 at 06:20:26PM +0530, Joe Steeve wrote: As I mentioned on a follow-up post, we figured the 'Persistent' part. :) On Wed, 2011-06-08 at 13:29 +0100, Laurence Rowe wrote: My guess is that the ObjectModifiedEvent is dispatched to your object's parent and causes something to change there, with the side effect of storing your updated object. Even if the object's parent (a btree-container) had changed, will it attempt to force-store its entire child-tree? I am trying to imagine the effect of it on a huge tree. The smallest unit that is ever written to a ZODB is one persistent object (with all its nonpersistent attributes/items, recursively). BTrees use multiple persistent buckets for their state and are very efficient, storage-wise. But this only matters when you're adding/removing items to a BTree. If you're modifying a persistent object stored in a BTree, the BTree itself remains unmodified and does not need to be re-written Likewise, if you modify a non-persistent attribute of a persistent object which also has some attributes which are themselves persistent, only that object is re-written. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3vtXcACgkQ+gerLs4ltQ6fMQCfcdevBmf4yA3HBnZal/8map5h q2sAnj7acU3CjN2DACvCA2Ij213VvW/k =w9IP -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On Wed, 2011-06-08 at 14:48 +0100, Laurence Rowe wrote: A BTree efficiently stores a large number of key,value pairs because the storage is split across a number of persistent objects (buckets) each of which stores a part of the tree, so only the bucket that changes needs to be stored when a key,value is updated. See http://zodb.org/documentation/guide/modules.html#btrees-package and http://en.wikipedia.org/wiki/B%2B_tree Okay. So, if there are (say) 10 objects in a bucket. And, one of them changes. Then, are all 10 objects serialized again? -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On 8 June 2011 20:47, Joe Steeve j...@hipro.co.in wrote: On Wed, 2011-06-08 at 14:48 +0100, Laurence Rowe wrote: A BTree efficiently stores a large number of key,value pairs because the storage is split across a number of persistent objects (buckets) each of which stores a part of the tree, so only the bucket that changes needs to be stored when a key,value is updated. See http://zodb.org/documentation/guide/modules.html#btrees-package and http://en.wikipedia.org/wiki/B%2B_tree Okay. So, if there are (say) 10 objects in a bucket. And, one of them changes. Then, are all 10 objects serialized again? If they are not persistent objects themselves then yes. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On Wed, 2011-06-08 at 21:46 +0100, Laurence Rowe wrote: Okay. So, if there are (say) 10 objects in a bucket. And, one of them changes. Then, are all 10 objects serialized again? If they are not persistent objects themselves then yes. Ok. That explains. Thank you :) -- Joe Steeve HiPro IT Solutions Pvt. Ltd. http://hipro.co.in/ signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BlueBream] Reg. persisting data in ZODB via forms
Hello Jonah, Thanks for the reply. On Wed, 2011-06-08 at 09:53 -0700, Jonah Crawford wrote: Joshua - persistence in zope occurs based on assignment of values. You have to explicitly assign the values your form collects to the object you're persisting. That object then gets pickled to the ZODB as long as there's an assignment to an object in the ZODB. Events have nothing to do with it. Post some code examples if this isn't helpful enough. I was trying to add a non persistent object to the BTreeContainer. I was of the notion that I don't need to make my object persistent explicitly, as I am adding it to the persistent btree container. The add operation was successful but the modify operation on my object failed to persist. Making my object persistent solved the issue. -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
