Hi all. I'd like to know if there's a portable way to locally access the information in the Z object database. By portable, I mean across future releases of BoboPOS2/3. One method would be to use the BCI (now Client) interface. BCI is very useful for testing and debugging applications, but less useful for direct data access. I'd like to navigate the database from a set of root objects in the database without being requested for authorization info. Read-only mode would be okay over the short-term, but eventually I'd want to directly modify items the database. In Boboland, these issues were much simpler, because the applications were almost entirely responsible for what went into the database -- which was essentially a glorified pickle with serialized transactions. Now that we're moving into an area where a large part of the database is managed outside of the user application, (not to mention concurrency issues) I'd be interested the direction database access appears to be heading. One possible departure point would be to start with Main.py and trace its procedures, but I thought I'd ask here first, and hear what others have to suggest. Best regards, Jeff Bauer Rubicon, Inc.
Hi all.
I'd like to know if there's a portable way to locally access the information in the Z object database. By portable, I mean across future releases of BoboPOS2/3.
One method would be to use the BCI (now Client) interface. BCI is very useful for testing and debugging applications, but less useful for direct data access.
I'd like to navigate the database from a set of root objects in the database without being requested for authorization info. Read-only mode would be okay over the short-term, but eventually I'd want to directly modify items the database.
Do you mean something like an 'object explorer'? With an explorer like interface to the DB? This idea was discussed on the Bobo list perhaps a month ago. I've convieved of such an application that lets you fly through the database, view object revisions, 'time travel' and detail the inner workings of objects like the HelpSys does now. This is all just ideas however and no code. I don't see how it could be so hard with a little Python and the #tree tag.
In Boboland, these issues were much simpler, because the applications were almost entirely responsible for what went into the database -- which was essentially a glorified pickle with serialized transactions. Now that we're moving into an area where a large part of the database is managed outside of the user application, (not to mention concurrency issues) I'd be interested the direction database access appears to be heading.
One possible departure point would be to start with Main.py and trace its procedures, but I thought I'd ask here first, and hear what others have to suggest.
Yes now that I think about it this is more than just the issue of descending down the Zope object tree. I believe Jim mentioned that the database topology was flat, with an object id to object mapping. I wonder if this flat mapping is clean enough to tree out into parent/child (container/contained) relationship for exploration.
Best regards,
Jeff Bauer Rubicon, Inc.
Michel
participants (2)
-
Jeff Bauer -
Michel Pelletier