On Sun, 2004-11-28 at 16:02, David Pratt wrote:
Hi Chris. This sound like the product I am seeking. The names being the same would be benefit since I am also hoping to make reference to the images in the filesystem from non-zope content.
That's fine.
Will having same names be a setting in the product?
It is, via the "naming expression" exposed by the product (a TALES expression), although it's much simpler to give it an "opaque" name rather than naming it after the Zope path of the object because then the product doesn't need to do anything when a file object moves or is renamed within the ZODB. If you name the file after the Zope path of the object, and the object moves or gets renamed, you need to go move the respective disk file. The product does not do this. You can override this via the naming expression, and cause the file to be created in a path that makes more sense to a human, but the naming expression needs to always generate the same path for the lifetime of the object (e.g. if you base the naming expression on the id of the object, but you later change the id of the object, it will fail to find the file). IOW, the naming expression needs to be "idempotent": for the lifetime of the object, it needs to generate the same path no matter what else might happen to that object. You can work around this as necessary by modifying MigratableFile/FilesystemTool but it's not supported out of the box. Out of the box, the product attaches a "filesystem id" to an object when it is added (a 32-digit hexadecimal number). A disk path is created from this filesystem id and the file lives on disk in the file named by this path for the lifetime of the object. Of course, the path is "gibberish", but that's by design; no one is tempted to change it once its been set. You can change the path, the id, the title, and so forth, and the filesystem id isn't effected. FWIW, if it's important for the files to created in a structure on disk that matches the Zope hierarchy and you aren't willing to write product code to help MigratableFile with this, you might look elsewhere (LocalFS?). From your original description, this didn't seem like a requirement.
I take it part of the file must still live in the zodb after the file has migrated - is this correct?
Yes. It's usually around 2 or 3k of data for a normal Zope file object.
Can the image or file still be used with static content in the typical way without any interaction with zope?
It's a file on disk, so to the extent that you can use a file on disk, yes. - C