On Tue, 19 Sep 2000, Brandon Metcalf wrote:
> Anyone have any comments on the cons of admin vobs and the improvement
> of their implementation from 3.x to 4.x?
On 3.x, global element types didn't work. I haven't tested them on 4.0
since I can continue to use the 3.x procedures, but I think I'll give it
another shot soon, since maintaining local element types in all vobs is
really a lengthy procedure...
On 3.x, renaming a global metadata type was a bitch. You had to actually
remove it from the adminvob, rename all the local types and recreate the
global type. In 4.0, it is enough to replace the type in the adminvob with
a local type, rename the local ones elsewhere and reacquire them, which is
a new feature. Apparently, if you upgrade your vobs to the new database
format (54), you can rename global types directly with the rename command,
but I haven't tested this.
Generally, 4.0 wants to ram the global types down your throat, and
commands like lstype will initially not differentiate between global types
defined in the adminvob and local types, even if there is no instance of
that type in the local vob. Also, rmtype -rmall on a global type will
always remove everything in all vobs, even if you explicitly specify a vob
as in: "rmtype -rmall brtype:branch@/vob/ordinary", which did surprise me
a little :).
I have not had the occasion to test all multisite implications yet.
In general, I like global metadata types, mainly because you get atomic
lock for all vobs. I worked around the 3.x flaws and the 4.0 surprises and
I think that they have become very useable.
-- cg- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:41 EDT