Sukhwinder Singh wrote at 2003-6-29 01:13 +0530:
... But there is not much information available on net about zodb.
Quantity is seldom a measure for quality... Did you find the ZODB3 description ("zodb3.pdf/zodb3.html")? Did you find the ZODB guide?
... There is not much information about how zope stores objects in zodb
That's because they are stored automatically and naturally. There is nothing the ZODB user must do. Storing and loading happens transparently. You just access objects naturally (as provided by Python) and modify them (there are some caveats for non-persistent mutable attributes). Everything else is done automatically be the ZODB in the background. Your problem is not a ZODB problem. Your problem is your lack of knowledge about the application! Any ZODB object contains data, but not all ZODB objects contain data relevant for your application. You access the content of your objects usually through an API. Which one is determined by your application and not by the ZODB. Usually, you use the "PropertyManager" or "PropertySheet" API to access properties and the "ObjectManager" API to access children. This is because most applications use properties to store elementary data and an object manager to store subobjects. But, applications are free to do it in any other way...
No documentation is available about how to retrieve already stored data about which I don't have any prior knowledge. As in java, ide's use introspection to determine what are fields and methods of a object (bean)
Maybe, you should read about Python's "inspect" module or its "dir" and "vars" builtin functions. Python's inspection support is at least as good as Java's... There is a (small) caveat when using "dir/vars" with objects from the ZODB: The ZODB loads object state only on demand from the database. "dir/vars" does not trigger this mechanism. Therefore, the object may appear empty (when is has not yet been loaded). Accessing any attribute (even one that does not exist) will load the object and "dir/vars" can be used to analyse its state.
. Other DBMS also allow us to determine how many tables etc. are there in database. But how do I do that with zope and zodb?
You do not because the objects are not organized into tables. The closest thing would be to determine the classes of objects stored in the ZODB. This is not supported (as people usually have more knowledge about their application than you have and do not need this service). It would not help you either because the object state is not determined by the class but by the instance itself.
I can access objects If I knew which objects store data
All objects store data... Your application documentation must tell you which objects store data relevant for the application. If it does not, this is not the fault of Zope or the ZODB but of the application development...
and how many fields are there in each object.
"dir" tells you the name of fields in any given object. "vars" gives you name and values...
Looking into every dtml file or other methods isn't possible in this shot period. Even If I did that I may miss some fields which are used in this application.
I fear we cannot help you much with this as we (of course) do not know your application better than you do ;-) Probably your best way: Start with the objects exported by the exporting script you mentioned in another post. These objects form a subset of the one relevant for your application. Analyse these objects with "dir". Many attributes will be internal, all starting with "_" will be. Would you know that your application stores attributes as properties, then the "PropertyManager" API methods would reveal them all. In the future, you should probably more careful when you accept client requests and time frames. Dieter