Feed on

My notes for the second and third day at the Plone conference in San Francisco.

How to think in Plone (when those  about you think in Drupal)

Dan Jacka

  • Let’s make switching to Plone easier
  • Plone content is naturally structured, drupal content has nodes indentified by numbers.
  • For Plone lots of content is a prerequisite
  • Confusions when coming from Drupal; content ‘lives’ where it appears and restrict locals adds with permission
  • ‘micro components’ are powerful ways to add functionality
  • Use micro components like dexterity behaviours, collective.contentleadimage, collective.watcherlist. Small products are good!
  • Big products are bad, if you only need to use a part and get unnecessary stuff you don’t need.
  • With Zope Component Architecture you can override specific parts in Plone, like the breadcrumbs 
  • Store data; With context use zope annotations and archetypes.schemaextender. Without context use plone.app.registry, portal_properties and local utilities
  • See:  http://www.martinaspeli.net/articles/dcworkflows-hidden-gems

ZODB tips and tricks

Carlos de la Guardia

  • See collective.zodbbrowser Provides access to all objects and their attributes
  • Eye is an external tool to browse the database, without having to install (in buildout)
  • OMG POSKey error: first backup! Fire up debugger, see  http://plonechix.blogspot.com/2009/12/definitive-guide-to-poskeyerror.html
  • Get rid of persistent utilities, see wildcard.fixpersistentutilities
  • Always backup first before trying to fix anything!
  • Restore data / do an undo from data that is deleted a long time ago. Use zc.beforestorage, a wrapper around storage to show site like it was on a certain date
  • RelStorage, drop in replacement for file storage. Designed for high volume sites, multiple zodb instances can share the same database. Starts quickly regardless of db size. Supports undo, packing blobs. Capable of fail-over to replicated databases.
  • Zc.zodbactivitylog (track db actvity), zodbshootout (benchmarks zeo vs relstorage), zodbupdate (helps you rename classes), dm.historical (get history of objects), dm.zodb.repair (restore lost objects)
  • See Products.ZMIntrospection to look in objects
  • Use PersistentDict for small amount of items, use OOBTree (and friends) for large amounts
  • Use BTrees.length instead of len, much faster and avoids conflict errors
  • Use zc.zlibstorage for dbs with lots of text, saves 60/70% of storage
  • Use zc.zodbgc an inverse graph of db
  • Increase the ZEO client cache size, when everything is crumbeling around you. When increasing round trips to ZODB are increased   

Carlos is writing a book on the zodb: http://zodb.readthedocs.org/en/latest/index.html 


Mistakes made and lessons learnt

Matt Hammilton And Matt Sital-Singh

  • Use case a e-learning system, lot of content, users editing content but not necessary aware of it, lots of clustering of load on resources
  •  30.000 user accounts, 160.000 messages, QA objects etc
  • Don’t create  ghost content. If you need shared content, it can be a good idea to don’t use subsites but sync the content
  • Use optimization products. See experimental namespace; queryplan, contentcreation, daterangeindexoptimisations, aggresiveopaquesetup, indexing. Most of them aren’t experimental anymore and are included in plone 4.2
  • Lot’s of answers/questions in catalog. Up to 1.400.000 qa objects. Uhm sql? Or catalog multiplex tool, separate these objects from main catalog.
  • Pre-load Catalog QueryPlan
  • Keep things you don’t need out of the catalog
  • If you know where something is – Don’t search for it. Hardcoding is ok
  • Use unrestrictedSearchResults if possible, the catalog has a lot less work to do
  • Maybe should not have used Plone. A lot of the data is relational.

Beginner mistakes. Expert failures

Alan Runyan


  • Use logging/sending email or long term persistence for error logs
  • Don’t mix dev/stage/prd concept/concerns
  • Don’t use directlyProvides or using the ZMI to apply marker interfaces
  • Do learn the profiler, see collective.stats (how many load/stores per request)
  • Don’t attempt to ‘normalize’ the model
  • Willing to claim defeat and backtrack; sometimes you simply do
  • When beginning development use an alpha, beta or RC. If the project is finished, chances are big a stable version is released.
  • Don’t be willing to take pain. Give feedback!


  • Using components early, not writing reusable code is ok.
  • Overloading too much functionality in view
  • Mounting / splitting ZODB in effort to make things faster
  • Using Plone inappropriately. Security, workflows, staging/versioning, content, add-on components.
  • See book scalability rules
  • Unwilling to thorougly understand tradeoffs between ZODB/RDBMS
  • Masking over performance problems with caching

Check out ploud and  ptah .

RelStorage is stable and is used in many production sites. It works with PostgreSQL, MySQL and Oracle. The rationale to use it is replication. SQL datbases can do this, the ZODB can’t.

Trackback URI | Comments RSS

Leave a Reply