BTW, I noticed that once you get an instance of the object, you *can* read the attributes (which of course correspond to the columns from the SQL query), but it doesn't let me change the values unless I create "wrapper methods" inside the class.
Is that a Zope security thing, bug, unimplemented feature... do you know?
I guess I can't really say, in that I don't have time to take a look at the source right now. If you would like my guess (which may very well not be worth the paper which it is not written on), I think this is probably intentional. Why? 1) it probably had to be expressly prohibited 2) allowing change to PBs would imply (to some, at least) a change in the source data, which doesn't happen. Unlike some of the newer parts of JDBC, changing the results of an SQL query in Pluggable Brain space does not have any effect on the actual stored data. If it did, it would be a nice little feature, but otherwise it would be an annoyance and (possibly) inconsistent. Depending on your mental model of how this sort of mapping works. So I imagine that locking it down was the most reasonable behaviour. (There are other areas in Zope, I believe, where this happens.) If you like, you can think about it as an unimplemented feature that has been safeguarded, although I doubt this was ever the original intent. Someone with reasonable SQL knowledge and a good bit of expertise into Zope/Python introspection might be able to make this real without too much work (or maybe not.) But don't hold your breath. --jcc