[Zope] Exporting zodb data (Urgent)

Dieter Maurer dieter@handshake.de
Sun, 29 Jun 2003 20:06:25 +0200


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