Re: Objectivity Question

[David Zimmerman <zimm@physgi01f.phy.bnl.gov>]

Hi Shigeki,
Here is a what one gets with V5b3.  More commentary follows
ooattachdb
    (-db dbSysName  -id oid  -filepath path) | (-dbmap mapFile)
    [-host hostName]
    [-standalone]
    [-notitle]
    [-quiet]
    [-help]
    [bootFilePath]
Attach a Database to a Objectivity/DB Federated Database. The Database 
should 
be generated by using oocopydb. The utility will fail if any of the 
following 
is true: 1) There is already a Database with the same name or identifier 
in the 
Federated Datbase. 2) The Federated Database is already using the 
Database 
File. 3) The file is not recognized as a valid Database File.
-db dbSysName    System name of the Database to attach.
-host hostName   Name of the host machine where the Database File is
                 located. Default is the current host.
-filepath path   Pathname of the Database File on host hostName.
-id oid          Object ID of the Database to attach. Use the format
                 D-P-C-S.
-dbmap mapFile   Name of file containing list of Databases to attach.
                 Format of each entry is: targetDBID dbSysName dbFileHost 
dbFilePath
-standalone      Run in non-concurrent mode. You may only use this flag if
                 the Lock Server for the Federated Database is not running
                 WARNING - corruption may occur if concurrent access to the
                 database is attempted while any process is using this mode.
-notitle         Don't print the program title banner.
-quiet           Suppress all normal program output.
-help            Print out a help message and exit.
bootFilePath     Path to a Boot File for the FD. If not specified, the value
                 of the environment variable OO_FD_BOOT is used.

I have been using this function to attach data bases from one federation to
another one.  In the administrators guide it says (on page 6-2)

"If you do not specifify the database ID to be assigned to the database, 
ooattachdb increments the highest database ID in the federated database
and assigns the resuling ID to the database."

(I believe this feature is not yet in the beta version I use)

Note that (more from page 6-2) you cant do this unless you have the same 
page size and schema as the fdb to which you are attaching.  Furthermore,
it will fail, if you try to attach a db which has the same 
systemname
database ID
filepath 
as a dbase already in the (new) federation.


> Okay. If I understand things correctly, the following situation crops
> up.
> 
> I have 3 federations, on-line, DAQ, and RCF/Recon.  Each federation is
> capable of creating data bases.  AFAIK, we have no control (see *)
> over the ID of a database on creation.  We also have no ability to
> change the ID of a database once it's created. (oocopydb and
> ooattachdb do NOT provide this functionality in either version 4 or
> version 5.)
> 
> Arbitrarily moving a data base from one federation to another is most
> likely going to fail because the ID of the data base being moved will
> clash with a pre-existing data base in the federation. (I recall
> reading that ID's appear to be assigned sequentially.)
> 
> (*) It appears that the only way out of this situation is to
> "pre-allocate" data base ID's by populating each of the three
> federations with "dummy" data bases that utilize the data base ID's of 
> the "real" data bases that will eventually populate the other data
> bases. In other words, given federations A, B, and C; federation A
> needs to be populated with dummy databases with the same ID's that the 
> real data bases created in B and C will have. This way, every data
> base created in A will be guaranteed to have an ID that is unique to
> A. In this scenario, we need to assign ranges of database ID's for
> each of the federations. 
> 
> This also means that when a data base is moved or copied from A to B
> for example, the procedure will be to oodeletedb the ID of the "dummy"
> database in B followed by an oocopydb and ooattachdb.
> 
> Is this correct, or did I mis-understand what you wrote.
> 
> Thanks
> 
> Shigeki
> 
> David Zimmerman writes:
>  > 
>  > > Does that mean that the functionality of ooattachdb has changed
>  > > between version 4 and version 5 ?
>  > > 
>  > > At least in version 4, ooattachdb only identifies the OID of the
>  > > database being attached. If the new federation already contains a
>  > > database with the same OID, you are SOL.
>  > > 
>  > 	Indeed.  That is what I was referring to with my comment about keeping
>  > track of dbase ID's.  I havent tried to attach a database with a 
>  > specified ID which is the same as an already existing dbase ID, but I 
>  > would think that the transaction would fail.
>  > 
>