- What's the next step on supporting ZODB Blobs? - Is there a branch of Zope that actually uses it? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
Hi, Sidnei da Silva wrote:
- What's the next step on supporting ZODB Blobs?
Start using it! :)
- Is there a branch of Zope that actually uses it?
Nope, not yet. I don't have any plans for Zope 2, but I'll be working on the Zope 3 side. I guess that we need to decide whether we want to release the current ZODB trunk together with the next releases of Zope (2 and 3). In this case we'll need a release branch for ZODB 3.8 and switch Zope to it. From my perspective, we could: - Have blobs available and let people pick them up. This option has the lowest potention for interrupting anybody's operation of existing applications/servers. - Make the existing File implementation use blobs This would be good so people see how to use them and get blobs widely exposed. Ideally, the Zope beta releases would uncover problems with existing applications/installations. - Make new "Big File" implementations based on blobs This would also allow people to see how to use blobs, but is a bit more conservative approach as blobs are a new feature and we don't want to destroy existing databases. Additionally, we could change the existing skeletons for zope.conf and zeo.conf to include a blob storage in their examples. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On 17. Dezember 2006 12:36:08 +0100 Christian Theune <ct@gocept.com> wrote:
- Make the existing File implementation use blobs
This would be good so people see how to use them and get blobs widely exposed. Ideally, the Zope beta releases would uncover problems with existing applications/installations.
Appears too risky to me ..
- Make new "Big File" implementations based on blobs
This would also allow people to see how to use blobs, but is a bit more conservative approach as blobs are a new feature and we don't want to destroy existing databases.
+1 Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFhS0tCJIWIbr9KYwRAufOAJ9p+Tamy3IINBkgj/TjosnOPEN7KQCg4Eyi BSVQxg/0/ohQJzB1N2oHb4M= =xP9d -----END PGP SIGNATURE-----
On 12/17/06, Andreas Jung <lists@zopyx.com> wrote:
- Make new "Big File" implementations based on blobs
This would also allow people to see how to use blobs, but is a bit more conservative approach as blobs are a new feature and we don't want to destroy existing databases.
+1
I'm fine with that. It's more likely that Archetypes will grow Blob support for it's FileField, which could be easier if OFS.File just used Blobs as that's what it uses under the hood, but it can also use Blobs directly. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
On 12/17/06, Christian Theune <ct@gocept.com> wrote:
Nope, not yet. I don't have any plans for Zope 2, but I'll be working on the Zope 3 side. ... - Make the existing File implementation use blobs
This would be good so people see how to use them and get blobs widely exposed. Ideally, the Zope beta releases would uncover problems with existing applications/installations.
There's more than one of these. zope.file was intended to use blobs when they come along, so I'd suggest that making that support blobs directly, with backward compatibility for the existing structure, is the right way to go. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca
Hi, Fred Drake wrote:
There's more than one of these. zope.file was intended to use blobs when they come along, so I'd suggest that making that support blobs directly, with backward compatibility for the existing structure, is the right way to go.
Intuitively my first guess is: a) provide a generation to convert old data structures b) keep the existing interfaces working If b) doesn't work we'll have to gracefully extend the interfaces in a backwards-compatible fashion. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
On 12/18/06, Christian Theune <ct@gocept.com> wrote:
a) provide a generation to convert old data structures
Since we tend to work with high-availability issues at ZC, I'm hesitant to go this route; expensive generations that affect large portions of a database can be very difficult to run without a significant maintenance window. For things like this that can affect a large number of objects that otherwise wouldn't be written to, I'm generally in favor of avoiding modifying the object and making the code compatible with the old data structures. Yes, this carries it's own risk (failure to be compatible) and cost (maintaining support for the old structures), but that can be mitigated through tests.
b) keep the existing interfaces working
I suspect this will be easy with zope.file, since it was specifically designed to work with blobs. The interface doesn't lend itself to having reasonable security declarations declared through ZCML (since the open() method is used for both read and write access), but that's a different failing (which I'd be happy to see fixed with an improved interface). -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Every sin is the result of a collaboration." --Lucius Annaeus Seneca
participants (4)
-
Andreas Jung -
Christian Theune -
Fred Drake -
Sidnei da Silva