Lotus Note ID详解

http://www-01.ibm.com/support/docview.wss?uid=swg27002668

 

UNID (Universal Note ID) - 唯一地确定了文档（note）, 不管它（note）是位于何处或所处何时.另一方面, 每个文档（note）的复本拥有相同的 UNID, 并且 UNID 不会因为文档的更改而变化.
OID (Originator ID) - 确定文档（note）的特殊的修订版本,不管它（note）位于何处，也就是说，每个文档（note）的复本拥有相同的 OID, 但是当文档（note）更改时OID也会随之修改.
GNID (Global Note ID) - 确定一个特殊数据库中的一个特殊文档（note），GNID 不会随文档（note）的改变而变化。一个文档（note）复本的GNID可能会不同，因为毕竟他们在数据库中的位置可能不同。
NID (Note ID) - 确定给定数据库中的一个特殊的文档（note）。NID 不包含数据库的信息（只在数据库内定位有效：译者注），并且文档（note）修改时不会变化。
IID (Instance ID) - 确定一个给定数据库中的一个文档（note）的特殊修订版本，IID 不包含数据库信息，文档（note）修改时，IID会变化。
GIID (Global Instance ID) - 确定一个特殊数据库中的一个文档（note）的特殊修订版本. GIID 包含数据库信息。The GIID 文档（note）修改时，IID会变化。
你可以从 Notes 用户界面可以检查 ID 的信息。在视图中选择一个文档并且打开它。然后选择菜单 文件 - 文档属性。Notes 显示“文档属性”信息框。在信息页，Notes 显示和这个文档相关联的数据信息，包括文档创建和修改的日期和时间以及note ID 信息。 note ID 信息显示成三行，包含关键字和16进制字符。对于一个典型的文档，通常是这个样子：
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

这三行包含所选文档 Originator ID (OID), Universal Note ID (UNID), Global Note ID (GID), 和 Note ID (NID) 。
The Universal Note ID (UNID) and the Originator ID (OID)
第一、二行组成了完整的 Originator ID， Originator ID 由 Universal Note ID （整个第一行）加上序列时间和序列号（第二行）：
Originator ID (OID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Universal Note ID (UNID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Sequence Time =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Sequence Number =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Originator ID (或 Universal Note ID)的前两部分由文件号（File member）和文档号（note member）组成。第一行由 /"OF/" (/"Originator ID - File/紧跟16个16进制字符，然后是连字符 /"-/" ，然后是 /"ON/" (/"Originator ID - Note/后面又是16个16进制字符。 /"OF/" 后面连字符之前的16个16进制字符构成了OID的文件号（File member）。/"ON/" 后面连字符之前的16个16进制字符构成了OID的文档号（note member）。
OID.File =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

OID.Note =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

在头文件 nsfdata.h 中包含了下面的定义 ORIGINATORID 数据结构和 UNIVERSALNOTEID 数据结构：
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called /"File,/" */
/* it doesn/'t have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
/* (THE ABOVE 2 FIELDS MUST BE FIRST - UNID */
/* COPIED FROM HERE ASSUMED AT OFFSET 0) */
DWORD Sequence; /* LOW ORDER: sequence number, 1 for first version */
/* HIGH ORDER WORD: flags, as above */
TIMEDATE SequenceTime;/* time/date when sequence number was bumped */
} ORIGINATORID;

#define OID ORIGINATORID

typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called /"File,/" */
/* it doesn/'t have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
} UNIVERSALNOTEID;

#define UNID UNIVERSALNOTEID

文档的 Originator ID (OID) 确定了同一个文档（note）的所有复本。OID 由两部分组成：Universal Note ID (UNID) 和序列号（sequence number）、序列时间（ sequence time）。 UNID 唯一的确定了同一个文档（note）的所有场合的复本。序列号（sequence number ）和序列时间（ sequence time） 放在一起区别同一文档（note）的不同版本。
Universal note ID (UNID) 确定了驻留在所有服务器上的同一个文档（note）。然而，UNID 缺少直接访问一个给定数据库中的文档（note）的信息。UNID 用于从一个文档来（note）引用另一个指定的文档（note）。答复文档中的/"$REF/" (FIELD_LINK) 域包含了其父文档的 UNID ， DocLinks（参见nsfdata.h中的 NOTELINK 数据结构）包含了链接文档（note）的 UNID ，和链接视图的 UNID 以及链接文档所在数据库的 ID （ViewLinks 包含了相同的信息，不同的是链接文档的那部分全部设为0， 而 DatabaseLinks 包含的信息是链接文档和链接视图的部分全部设为0） 。UNID 的重要特征是它能总是确定同一个文档（），不论它是否更新过。
UNID, the OID, 和复制器（ Replicator）
Universal Note ID （Originator ID的第一部分） 唯一的确定了同一文档（note）的所有版本和复本。如果两个文档（note）具有相同的UNID则它们互为复本。因此，相同文档（note）的所有复本的不同版本都有相同的 UNID。这就导出一个必然的结论：一个数据库中不能含有两个具有相同UNID的文档（note）。如果复制器（replicator）发现同一个数据库中两个文档（note）具有相同的UNID，它就会产生一个错误消息写到日志里，并且不对文档进行复制。
完整的 Originator ID, 从另一个方面唯一地确定了一个文档（note）的一个特殊版本。就是说，一个文档的相同版本的复本具有相同的OID。同时，一个文档（note）复本修改后，它就会有不同的OID。因为在文档（note）被编辑后， Domino 和 Notes 会增加序列号（sequence number）和序列时间（sequence）。 当文档（note）的一个复本保持不变，而另一个复本被编辑并修改，于是这两个复本具有相同的 UNID但是序列号（sequence number）和序列时间（sequence times）不同，因此OID也不同。
Domino 复制器（replicator）使用UNID 来匹配数据库中的文档（note），例如：如果数据库A和数据库B进行复制，数据库A中有个文档含有特殊的UNID，但是数据库B中没有，于是复制器（replicator）在数据库B中创建一个该文档的复本拷贝。
如果数据库A中包含一个文档（note）同时数据库B中有个文档（note）和它有相同的UNID，复制器（replicator）推断这两个文档（note）是同一个文档的两个复本。这种情况下，复制器（replicator）继续检查两个文档的序列号（sequence number ）和序列时间（sequence time），然后复制器（replicator）推断是否是同一时间更新过需不需要复制。如果序列号（sequence number ）或序列时间（sequence time）其中有一个或两个都不同，复制器必须决定哪一个是最近更新的哪一个比较旧一点。
如果其中一个更新过，而另一个未更新过，这样第一个复本的序列号会比第二个复本的序列号大，复制器（replicator）根据这种情况使用第一个复本覆盖第二个复本，从而达到两个数据库同步的目的。
复制冲突
复制冲突（Replication conflicts）发生在同时编辑并保存同一个文档（note）。如果用户修改了数据库A中的一个文档复本，而另一个数据库B中的文档复本也被修改（所作修改都在上一次成功复制之后，下一次复制之前），于是两个文档复本具有相同的序列号（）但是序列时间不同。这种情况下，复制器产生一个复制冲突，因为一个文档的两个复本在同一时期都进行了修改。（如果把一个文档的多个复本看成是同一个文档的话，这就表示同一个文档同时被修改。）
复制器通过生成复制冲突文档处理这种复制冲突。序列时间较早的文档（document）被标志为冲突文档。两个数据库中将会具有两个文档，只不过序列时间较早的文档会成为序列时间较晚的文档的答复文档。
复制器产生复制文档冲突，会在冲突文档前标志黑色菱形标记。复制器把序列时间较晚的文档拷贝到序列时间较早的文档所在的数据库中，并完整的保持它的 OID。 然后复制器把序列时间较早的文档转成一个新的文档生成一个截然不同的 OID 并给它增加一个特殊的条目 /"$Conflict/" (VIEW_CONFLICT_ITEM) 。 这个 $Conflict 条目会使文档在视图的左边显示一个黑色的菱形标记，表示它是一个冲突文档。 复制器也会给这个冲突文档增加一个$REF 条目使他变成答复文档，$REF 条目中含有其父文档（序列时间较晚）的UNID。
注意： 冲突文档（黑色菱形标记文档）并不总是立刻出现在两个服务器上。当拥有序列时间较晚文档的服务器发起复制时，冲突文档不会立刻在复制完成后出现在这个服务器上，但是会出现在那个拥有序列时间较早文档的服务器上。这是因为复制器仅在拥有序列时间较早文档的服务器上产生复制冲突文档（黑色菱形标记）。
特殊地，当服务器B初始发起复制，首先服务器B从服务器A拉（PULL），然后服务器A从服务器B拉（PULL）。当服务器B从服务器A拉动改变时，B看到了A上的冲突文档，发现B上的文档较新（序列时间较晚），所以不会把A上的冲突文档拉到B上。这样做的理由是因为B已经是最新的文档了，不需要再取得旧的文档了。然后 A 从B拉动改变，看到B上的文档较新，因此A把自己的较旧的文档变成复制冲突（黑色菱形），并把B上的较新的文档拷贝到A上。这就满足复制的需要：使数据库保持最新的同步。于是冲突文档（较晚的）不会出现在B上。下一次服务器B和服务器A进行复制时，冲突文档（较晚的）就会出现同时出现在两个服务器上达到同步的目的。
The OID and the API
API 程序使用 NSFNoteGetInfo 来获得 Originator ID 的不同构件，可以指定 _NOTE_OID 标志位，例如：
ORIGINATORID NoteOID;

/*
* Get the OID from the note AFTER it has been updated
*/

NSFNoteGetInfo (hNote, _NOTE_OID, &NoteOID);

NSFNoteUpdate 导致 Domino 和 Notes 改变正在更新的文档的序列号（sequence number）和序列时间（sequence time）。 因此， API 程序特别注意他们调用 NSFNoteUpdate 和 NSFNoteGetInfo 的顺序。
特别的，使用 NSFNoteCreate 创建一个新文档（note）获得文档的句柄后，直到这个文档保存到数据库中（使用 NSFNoteUpdate），NSFNoteGetInfo 才能返回有效的 OID。但是，既然这时 UNID 已经被赋值，所以 API 程序能够使用 NSFNoteGetInfo 分析并返回新建文档的 UNID 。
UNID.File
OID的文件号（File member ）包含了一个号码，依赖于 Domino 或 Notes 的不同版本。 Notes 2.1之前的版本中，文件号表示数据库文件创建的时间和日期。Notes 2.1 版本设置文件号（File member）跟用户有关的唯一标志符，一部分取自创建文档的用户的ID，一部分取自文档所在的数据库。Notes 3.0 及以后版本文档创建后把文件号（File member）设置成一个随机的号码。
UNID.Note
OID的文档号（Note member）是文档创建的时间。 （详细信息参见数据结构 TIMEDATE ）
Global Note ID (GNID) and NOTEID (NID)
Global Note ID (GNID) 由两部分组成：数据库 ID 和文档ID（Note ID）。既然 GNID 确定数据库和数据库中的文档，所以它可以唯一的确定所有数据库中所有文档的所有复本。
GNID 出现在 ID 信息的最后一行（使用 Design - Document Properties信息框）。第一部分对应数据结构 GLOBALNOTEID 的文件部分（File member），第二部分对应数据结构 GLOBALNOTEID的 NoteID 部分。
Global Note ID (GNID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Database ID (GNID.File) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

Note ID (GNID.NoteID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092

第三行开始是字符 /"DB/" （表示 /"Data Base/"），紧跟16个16进制字符，然后是连字符，然后是 /"NT/" (/"NoTe/"[img]mkMSITStore:跟着是8个16进制字符。在/"DB/" 后连字符前的16个16进制字符构成了 GNID的文件号（File member）， /"NT/" 后的8个16进制字符构成 Note ID 。
Global Note ID (GNID)
不象 OID，GNID 不能区别同一文档的不同版本，因为 NoteID 和包含文档的文件有关，所以文档复本的 GNID 很可能不同。
Database ID （GNID的文件部分）包含了数据库的复本ID（replica ID），API 头文件 nsfdata.h 定义 DBID 数据结构为 TIMEDATE类型：
#define DBID TIMEDATE

这个 8-byte DBID 包含了数据库原始创建的 TIMEDATE。你可以验证GNID的文件号（File member），显示在 File - Document 属性对话框，将会和数据库的 Replica ID相同，它显示在 File - Database 属性信息框。因为一个特殊数据库中的所有复本都有相同的 DBID，所以一个数据库中的所有复本数据库中的所有文档都有相同的 GNID.File.
typedef struct {
DBID File; /* Creation Date/Time of NSF where note was created */
NOTEID NoteID; /* Note/'s RRV in this file */
} GLOBALNOTEID;

#define GNID GLOBALNOTEID

Note ID (NID)
note ID (NID) 确定数据库中的一个文档。NID 是文档（note）的记录重布置向量（Record Relocation Vector (RRV)）的文件位置。一个 RRV 是一个 DWORD 型的偏移量。 因为 note ID 有时会被描述为 /"the Note/'s RRV in this file./"，所以常会导致错误的理解。事实上，note ID 对于 RRV来讲是在文件中的偏移量，表示文档记录的入口点。RRV 是一个基本的数据结构，而 note ID 则更加明确。在 Domino 和Notes 内部，除了文档之外的其他不同对象也都有相关的 RRV。
typedef DWORD RRV;
typedef DWORD NOTEID;

在一个数据库文件中，note ID 保证不会改变，除非这个文档被删除。当文档被删除时，note ID中的RRV_DELETED 标志位被设置。
#define RRV_DELETED 0x80000000L /* indicates a deleted note */

因为 note ID 在数据库文件中是明确的，其他数据库中的同一文档的复本拷贝很可能会有不同的 note ID。 INSTANCEID (IID) Instance ID 表示给定数据库中的文档对象的实例。每次文档（note）被修改，Domino 或 Notes 使用时间和日期标志 instance ID。Instance ID 由文档修改的 TIMEDATE 和 note ID组成。
typedef struct {
TIMEDATE Note; /* Note/'s MODIFICATION date/time */
NOTEID NoteID; /* Note/'s RRV */
} INSTANCEID;

#define IID INSTANCEID

文档修改的 TIMEDATE （数据结构IID中的 Note 部分）和OID的修订时间不是相同的概念。数据库视图使用文档（note）的 IID 修改时间 来决定什么时候显示未读文档标志。你可以使用NSFNoteGetInfo 并指定 _NOTE_MODIFIED 标志位来访问IID修改时间。 复制器使用OID的修订时间（Revision Time）来比较不同数据库中文档的复本。 可以使用NSFNoteGetInfo 并指定 _NOTE_OID 标志位来访问OID修订时间。
IID的 NoteID 部分是和GNID的 NoteID部分值相同。
NSFNoteUpdate 每次 NSF 文件更新时更新修改时间，这个修改时间（modification timedate）控制视图显示未读文档标记。
一个API程序有几种方式得到 IID ，从GNID 中取得Note ID，NIFReadEntries 缓冲区或者 SEARCH_MATCH数据结构的ID的NoteID 部分 。从SEARCH_MATCH数据结构的ID的NoteID 部分，或者调用 NSFNoteGetInfo 并指定 _NOTE_MODIFIED标志位来获取修改时间
GLOBALINSTANCEID (GIID)
Global Instance ID 是跨数据库的文档（note）实例。它包含了 Instance ID 的相同的部分并且增加了 database ID作为文件号。带有最近修改时间的文档是最新（ /"most recent/"）实例。
typedef struct {
DBID File; /* database Creation time/date */
TIMEDATE Note; /* note Modification time/date */
NOTEID NoteID; /* note ID in database */
} GLOBALINSTANCEID;

#define GIID GLOBALINSTANCEID

API 程序能够初始化一个 GIID 数据结构给文档，通过调用 NSFDbIDGet 来获得文件号，调用 NSFNoteGetInfo并指定_NOTE_MODIFIED 来获得对应于修改时间的部分。