On Mon, Oct 08, 2001 at 04:05:46PM +0200, Heine, Dieter wrote: > > Wait, this means that sitegroup with the same GUID already existed? > > If so then I don't understand your problem. > > The existing sitegroup has been 'worked around' by eleminating the > sitegroup field inside of the xml file ? (sorry for that, but I still > have questions) > > > What do you understand by 'conflicting'? Repligard definition of conflict > > is 'has same GUID'. > > I understood that every record in a sitegroup has a sitegroup id. If > there already exist a sitegroup with a given id then the sitegroup to be > importet may conflict with it > > > > What if the SG to be importet already exists on the new midgard ? > > Then 'changed' field comes to game. Repligard does not treat sitegroups > > specifically but libmidgard does. > > So what is after the import ? Changes libmidgard every sitegroup id > during the import ? > > Let's avoid misunderstandings: We are talking about the id field now not > the GUIDs. Usual records have autoincrement to avoid conflicting record > ids. The sitegroup id is also a unique id. I'd like to know if there is > also a dynamic mechanism like autoincrement to ensure uniqueness ? If > so, how is sitegroup id managed ? If not, why is uniqueness of > sitegroup's id not required ? Repligard or any other frontend for Midgard creates GUID when resource is created. At that time GUID and resource id (ID) are associated and the association is never been changed during lifetime of resource (in usual circumstances, of course). When replication is occured and non-existent resource is imported into database, new empty record is added into corresponding table and then this record is updated using actual values of resource. First step (creation) is so-called 'delay resource creation' when another resource has a link to this one but the resource itself doesn't exist yet in the database. Therefore, 'INSERT' statement is issued and autoincremented ID is generated. MySQL guaranties us its uniqueness and we have GUID unique as well, so at the 'repligard' table new mapping is created -- between GUID and newly generated autoincremental ID. Thus, uniqueness is maintained.
Repligard uses only GUIDs and 'changed' fields for making decisions. If GUIDs are similar, 'changed' field determines actual update. But if you have a SG with same attributes as that one you're trying to import but with different GUID, Repligard will treat them as different entities. -- / Alexander Bokovoy $ cat /proc/identity >~/.signature `Senior software developer and analyst for SaM-Solutions Ltd.` --- A dwarf is passing out somewhere in Detroit! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
