[Zope-dev] Zope Tests: 35 OK, 10 Failed
Summary of messages to the zope-tests list. Period Sat Aug 7 12:00:00 2010 UTC to Sun Aug 8 12:00:00 2010 UTC. There were 45 messages: 6 from Zope Tests, 13 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 5 from ct at gocept.com, 13 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Total languishing bugs for zopetoolkit: 115 From: ct at gocept.com Date: Sat Aug 7 20:36:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018061.html Subject: FAILED : Total languishing bugs for zope: 101 From: ct at gocept.com Date: Sat Aug 7 20:41:05 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018062.html Subject: FAILED: Repository policy check found errors in 407 projects From: ct at gocept.com Date: Sat Aug 7 21:15:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018064.html Subject: FAILED : winbot / ztk_dev py_244_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:08:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018074.html Subject: FAILED : winbot / ztk_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:15:24 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018075.html Subject: FAILED : winbot / ztk_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:22:01 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018076.html Subject: FAILED : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:29:03 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018077.html Subject: FAILED : winbot / ztk_10 py_244_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:37:25 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018078.html Subject: FAILED : winbot / ZODB_dev py_270_win32 From: buildbot at winbot.zope.org Date: Sun Aug 8 03:11:38 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018090.html Subject: FAILED : winbot / ZODB_dev py_270_win64 From: buildbot at winbot.zope.org Date: Sun Aug 8 04:07:28 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018091.html Tests passed OK --- Subject: OK : Total languishing bugs for zopeapp: 0 From: ct at gocept.com Date: Sat Aug 7 20:30:20 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018060.html Subject: OK : Total languishing bugs for zope2: 0 From: ct at gocept.com Date: Sat Aug 7 20:45:09 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018063.html Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Aug 7 21:36:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018065.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Aug 7 21:38:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018066.html Subject: OK : Zope-2.12 Python-2.6.5 : Linux From: Zope Tests Date: Sat Aug 7 21:40:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018067.html Subject: OK : Zope-2.12-alltests Python-2.6.5 : Linux From: Zope Tests Date: Sat Aug 7 21:42:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018068.html Subject: OK : Zope-trunk Python-2.6.5 : Linux From: Zope Tests Date: Sat Aug 7 21:44:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018069.html Subject: OK : Zope-trunk-alltests Python-2.6.5 : Linux From: Zope Tests Date: Sat Aug 7 21:46:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018070.html Subject: OK : Bluebream / Python2.4.6 32bit linux From: ccomb at free.fr Date: Sat Aug 7 22:06:20 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018071.html Subject: OK : Bluebream / Python2.5.2 32bit linux From: ccomb at free.fr Date: Sat Aug 7 22:06:25 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018072.html Subject: OK : Bluebream / Python2.6.4 32bit linux From: ccomb at free.fr Date: Sat Aug 7 22:06:27 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018073.html Subject: OK : winbot / ztk_10 py_254_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:45:08 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018079.html Subject: OK : winbot / ztk_10 py_265_win32 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:52:21 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018080.html Subject: OK : winbot / ztk_10 py_265_win64 From: buildbot at winbot.zope.org Date: Sat Aug 7 22:59:29 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018081.html Subject: OK : winbot / ZODB_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sun Aug 8 00:26:03 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/018082.html Subject: OK : Zope 3.4.1 KGS / Python2.4.6 32bit linux From: ccomb at
Re: [Zope-dev] Changing and migrating persistence structure
Hi Jim,
On 08/08/2010, Jim Fulton j...@zope.com wrote:
On Thu, Aug 5, 2010 at 2:36 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
...
I have a package (plone.registry) that currently has a persistent
structure like this:
Registry(Persistent)
|
+-- Records(Persistent)
|
+-- BTree of Record(Persistent)
|
+-- PersistentField(Persistent)
That is, a Registry is a persistent object containing a persistent
Records object that in turn contains a BTree of persistent Record
Since BTrees are mapping, I assume that you mean the values are
records and that the keys are something boring like strings or
integers.
Yes. The keys are strings.
I like to use mathematical notation when talking about BTrees and
sets, as in:
Registry
BTree {? - Record}
objects that contain a persistent PersistentField and a primitive
value.
This is quite inefficient, though, because it results in a lot of
object loads. On any given request, some of our projects load a dozen
or more values from the registry. Each is just a simple primitive, but
we need to load the full shebang to make it work.
Not sure what you mean by full shebang.
The Registry, Records object, the relevant Record in the relevant
BTree, and possibly the PersistentField object.
In the new branch it just looks up the value in the relevant BTree.
Now, I'd like to move to this structure:
Registry(Persistent)
|
+-- Records
|
+-- BTree of Field
|
+-- BTree of values
I'm foggy on what field and value are here or what your queries
are doing. Maybe this is just a distraction.
Somewhat, unless you've worked with plone.registry. The point is to
allow the get a value API to just look at self.values[key], which is
a fast lookup and doesn't load anything except the relevant BTree
bucket + the registry itself.
Here, there's only one Persistent object, plus the two BTrees: one
holding all the fields and one holding all the values. Records no
longer needs to be persistent (its attributes become part of the
parent Registry's _p_jar).
I wonder what role Records plays independent of the Registry.
None, really. The main reason to have it is to be able to have an API
like registry.records with dict-like notation (there's also
__getitem__ on the registry, which returns the value of a given key,
not the Record). I made ``records`` an attribute of type Records, and
Records derives from Persistent. I wish I hadn't, since it can just
live in its parent's _p_jar.
I also wonder why it matters whether it is persistent or not.
It's better if it isn't (one fewer object to load/fill up the cache),
though the real culprits are the many Record objects each being
persistent and loaded separately.
On a given request, we can end up loading a dozen or more values from
the registry, which means a dozen or more objects in the cache and
associated overhead.
Fields no longer need to be persistent
either, since they are in effect immutable objects. Values are
primitives anyway.
I've done this (in a branch) and it works for new sites. However, I'm
having a nightmare trying to migrate old sites. As soon as I access
anything that uses the registry, I get ZODB errors, because the
persistent structure is now different. In particular, it's trying to
read a value into e.g. a Records object that used to derive from
Persistent, but now no longer does.
What savings do you get by making Records non-persistent?
One fewer persistent object.
I think the real saving is in making the Record object non-persistent,
especially since the read use case can just read from the ``values``
BTree with the structure above.
What is the best way to manage this type of migration?
Today, it probably makes the most sense to make new classes for the
non-persistemnt objects. You'll then need to write a script to
rebuild the data structures.
Okay. So there's no way to get at the data if I take Persistent out of
the base classes for Records / Record.
Martin
___
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] Changing and migrating persistence structure
On Sun, Aug 8, 2010 at 2:21 PM, Martin Aspeli optilude+li...@gmail.com wrote: On 08/08/2010, Jim Fulton j...@zope.com wrote: On Thu, Aug 5, 2010 at 2:36 AM, Martin Aspeli optilude+li...@gmail.com wrote: What is the best way to manage this type of migration? Today, it probably makes the most sense to make new classes for the non-persistemnt objects. You'll then need to write a script to rebuild the data structures. Okay. So there's no way to get at the data if I take Persistent out of the base classes for Records / Record. There should be some way of doing this with custom __getstate__ and __setstate__ methods. It's just tricky to get right and a bit fragile. It's much easier to write the migration code if both the old and new class are separate and functioning at the same time. Hanno ___ 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] SVN: Zope/trunk/ Replaced failUnless with assertTrue and failIf with assertFalse in tests.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Log message for revision 11: Replaced failUnless with assertTrue and failIf with assertFalse in tests. Hmm, I don't like the way 'asseertTrue' and 'assertFalse' read -- is there a particular rationale for this change beyond personal taste? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkxfKPkACgkQ+gerLs4ltQ5H+wCfTguS8zUczqF0C7KmEyGywsmh 05EAnAqFFrfvP7pDohhL5cPGJ20Ka+2E =QYtc -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] SVN: Zope/trunk/ Replaced failUnless with assertTrue and failIf with assertFalse in tests.
On Mon, Aug 9, 2010 at 12:00 AM, Tres Seaver tsea...@palladion.com wrote: Hanno Schlichting wrote: Log message for revision 11: Replaced failUnless with assertTrue and failIf with assertFalse in tests. Hmm, I don't like the way 'asseertTrue' and 'assertFalse' read -- is there a particular rationale for this change beyond personal taste? The fail* methods are deprecated in Python 2.7's unittest module. Following the there should only be one way rule, I guess. More details at http://www.voidspace.org.uk/python/articles/unittest2.shtml#deprecations Hanno ___ 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] Changing and migrating persistence structure
On 8 August 2010 20:29, Hanno Schlichting ha...@hannosch.eu wrote: There should be some way of doing this with custom __getstate__ and __setstate__ methods. It's just tricky to get right and a bit fragile. It's much easier to write the migration code if both the old and new class are separate and functioning at the same time. The main problem is that the advertised API says you should do: from plone.registry import Record from plone.registry import field registry['foo.bar'] = Record(field.TextLine(), umy value) Here, field.TextLine derives from PersistentField which derives from Persistent, and Record derives from Persistent also. If I wanted to get rid of the Persistent base, I'd have to make a new tree of field types (the standard zope.schema ones still need some subclassing), and a new Record class with a less obvious name. Martin ___ 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 )
