2009-06-08 11 views

答えて

1

日付またはあなたが好きな任意の技術を使用して一緒に数の最初の部分を置くことができ、文書を保存するとき(EJ。「PO」&形式(日付、「YYYYMMDD」)& confDoc.getitemvalue(「doccounter」 ))。

カウンタについては、設定文書に保存して、各文書を保存するときに更新するのが好きです。日中に作成された文書が多数ある場合、構成文書の担当者との競合が発生する可能性があります。この場合、サーバー上のエージェントに実際に番号を割り当てることができますが、欠点は、保存するときにすぐに番号を取得しないでください。

これが役に立ちます。

+0

ちょっとメモ;次の番号を取得する前に、構成文書のロックの競合を避けることができます。クライアントが管理サーバーからカウンタをフェッチできるときにだけ番号を割り当てる場合は、かなり安全です。 –

+0

非常に良い点。私はドキュメントをロック機能では、私は恒久的にロックされたドキュメントを持っていたと慎重になると、他の奇妙なものが起こる。 – Carlos

1

単純ではありません。

一意のキー用のフィールドを作成し、このキーをオンにしてsave(または他のイベント)を保存しますが、この番号を一意にする必要があります。

ドミノサーバー上の番号を確認するエージェントを作成し、エージェントが競合を検出した場合は、アプリケーション管理者または他の責任者にこれを解決するように通知できます。

各レプリカは独自の番号を生成し、ドミノでレプリケートした後、エージェントは正しい形式で番号を割り当てます。

1

ヘルプデスクでは、現在のユーザーの頭文字を取って、最後のドキュメントの番号にビューに追加する方法があります。番号に1を加えて、新しい文書とititalsおよび新しい番号をキーとして格納します。

1

ドミノに「ほとんど」固有のキーを作成するには、単純に@Unique関数を引数なしで使用できます。これにより、現在のユーザーの姓と名、現在の時計時刻に基づいて文字列キーが生成されます。あなたは "ESCR-12345678"のような文字列で終わるでしょう。

私は「ほぼ」ユニークですが、これはSQLのID列が本当に似ていないためです。ドミノは特定の文字列を一度しか出さないことを保証しません。一度に多数のIDを生成するサーバーサイドエージェントで@uniqueを使用する場合(ループ内で@uniqueをループして使用するエージェントなど)は、作成するために@uniqueが複製を返す状況に陥ります2つのドキュメントが同じ秒間に表示され、「ユーザー名」が常にサーバーの正式名であるためです。しかし、このシナリオの外では、@ユニークは一般的に安全です。

このIDでドキュメントを開くか参照する必要がある場合は、そのIDでソートされたビューを作成するだけで、../myView/id?readDocumentという形式のURLを作成できます。

関連する問題