I'm currently trying to think through how to implement IKeyReference for
files on the filesystem. The end goal is to be able to use the intids
service on these files, so that they can be cataloged.
The simplistic approach to implement key references for files is simply
to use the filesystem path as key reference: the path is easy to
determine, and it's easy to resolve back to the file.
Unfortunately this doesn't work in the case where the files can be moved
on the filesystem.
I foresee two scenarios in which files could be moved: one through a web
UI (sending out the appropriate IObjectMovedEvent and so on). The other
is on the filesystem, were files could be moved during, for instance, an
SVN update (the idea is to be able to store the file data in SVN but
expose it as Zope-ish objects).
The scenario of the UI is more important to me so let's forget about
non-UI moves for a moment.
Suddenly, using a filesystem path for IKeyReference becomes broken. When
a file moves, the keyreference breaks.
One solution would be to create a special index that lists to all the
appropriate move events and updates the paths. This would be somewhat
similar to the way the ZCatalog maintains itself. It just seems annoying
to have to write an index to be able to index. :) Getting this right is
Another approach involves storing unique ids of some kind inside the
files themselves. This would be a possibility, but of course a move
shouldn't require a full directory walk in order to find the file of a
particular id again. It would help with filesystem level moves somewhat
but I said I wasn't going to worry about them. It would still require
the creation of a separate index.
Now I'm hoping I'm missing some kind of strategy and perhaps someone
will have a luminous idea to make this work without the creation of a
separate index. Or if not, at least I can give up looking and just go
and write that index. Does anyone have any suggestions?
Zope3-dev mailing list