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)
- 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/
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.
- Get rid of persistent utilities, see wildcard.
- 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
- 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
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
- 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
RelStorage is stable and is used in many production sites. It works with PostgreSQL, MySQL and Oracle. The rationale to