Comments on: #loveszodb http://jstahl.org/archives/2009/03/09/loveszodb/ Politics, the environment, technology, activism. And stuff. Wed, 02 May 2012 15:47:52 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Raphael Ritz http://jstahl.org/archives/2009/03/09/loveszodb/comment-page-1/#comment-393777 Raphael Ritz Wed, 11 Mar 2009 09:38:55 +0000 http://blogs.onenw.org/jon/?p=1704#comment-393777 <p>If you mean Plone as in Zope2/CMF/Archetypes/ATContentTypes/Plone I agree with Malthe. But if we are lucky (and contribute) some of this might get better with Plone 4 already.</p> If you mean Plone as in Zope2/CMF/Archetypes/ATContentTypes/Plone
I agree with Malthe. But if we are lucky (and contribute) some of this might get better with Plone 4 already.

]]> By: Alexander Limi http://jstahl.org/archives/2009/03/09/loveszodb/comment-page-1/#comment-393774 Alexander Limi Tue, 10 Mar 2009 08:40:27 +0000 http://blogs.onenw.org/jon/?p=1704#comment-393774 <p>+1.</p> <p>And Malthe, we're well aware that we're abusing the ZODB, but "we were young and needed the money." ;)</p> <p>I know we're planning to clean up a lot of this in the near future, so your comments/suggestions/patches are always welcome.</p> +1.

And Malthe, we’re well aware that we’re abusing the ZODB, but “we were young and needed the money.” ;)

I know we’re planning to clean up a lot of this in the near future, so your comments/suggestions/patches are always welcome.

]]> By: Malthe http://jstahl.org/archives/2009/03/09/loveszodb/comment-page-1/#comment-393773 Malthe Tue, 10 Mar 2009 07:46:30 +0000 http://blogs.onenw.org/jon/?p=1704#comment-393773 <p>This is so very true, Jon. In my experience, projects that are SQL-based often suffer from bad architecture, probably because developers are having to think too much about how to store their data.</p> <p>One downside of the ZODB is that there isn't a <em>strict</em> mode in which you can formally require data to be of a certain kind. There's some room for hard-to-track errors there, but it can be alleviated by writing good tests.</p> <p>If you only store numbers and text in the ZODB and use cataloguing with care (e.g. unlike Plone), it's very hard to beat the ZODB. There are some downsides (non-standard, questionable scaling, doesn't like writing too much) and you need to be aware of these.</p> <p>Plone really abuses the ZODB and it's a shame, because it's needless. With better datastructures, leaner objects and a minimum of thought, Plone and ZODB could live in perfect harmony.</p> This is so very true, Jon. In my experience, projects that are SQL-based often suffer from bad architecture, probably because developers are having to think too much about how to store their data.

One downside of the ZODB is that there isn’t a strict mode in which you can formally require data to be of a certain kind. There’s some room for hard-to-track errors there, but it can be alleviated by writing good tests.

If you only store numbers and text in the ZODB and use cataloguing with care (e.g. unlike Plone), it’s very hard to beat the ZODB. There are some downsides (non-standard, questionable scaling, doesn’t like writing too much) and you need to be aware of these.

Plone really abuses the ZODB and it’s a shame, because it’s needless. With better datastructures, leaner objects and a minimum of thought, Plone and ZODB could live in perfect harmony.

]]>