質問

ここに2つの質問があります:

質問1:

- スリフトはインナークラスの機能を提供できますか? (次の私の例を参照)

- 可能であれば、そのような機能を簡単に使用できますか?

これがScribeインターフェイス(Scribe/if/Scribe.thrift)です。しかし、そのメッセージフィールドは文字列のみである可能性がありますが、これは十分に柔軟ではないと思います。

#!/usr/local/bin/thrift --cpp --php

##  Copyright (c) 2007-2008 Facebook
...
...
## See accompanying file LICENSE or visit the Scribe site at:
## http://developers.facebook.com/scribe/

include "fb303/if/fb303.thrift"

namespace cpp scribe.thrift

enum ResultCode
{
  OK,
  TRY_LATER
}

struct LogEntry
{
  1:  string category,
  2:  string message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

次のことをすることができれば素晴らしいでしょう(Thrift自体がそのドキュメントに従ってインナークラスの機能を提供するかどうかさえわかりませんが、プロトコルバッファーは間違いなくできます)。

enum ResultCode
{
  OK,
  TRY_LATER
}

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry
{
  1:  string category,
  2:  MyLogStructure message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

質問2:

-Scribeは、内部データ表現としてプロトコルバッファーを簡単に使用できますか? (コードの変更があまりない)

- 上記の質問に対する答えが「いいえ」である場合、GoogleはSRIBEの実装をオープンソースしましたか?

正しい解決策はありません

他のヒント

はい、Thrift structには他の構造体を含めることができ、あなたの定義(繰り返される以下)が機能します。

enum ResultCode { OK, TRY_LATER }

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry {
  1: string category,
  2: MyLogStructure message 
}

service scribe extends fb303.FacebookService {
  ResultCode Log(1: list messages);
}

このようなScribeのインターフェイスを再定義した場合、おそらく、Scribeのコードを変更して、内部的に行うことに応じて新しいタイプを処理する必要があります。 string message.

もちろん、いつでもシリアル化できます MyLogStructure 文字列に反対し、この問題を完全に回避します。

いいえ、Scribeは内部データ表現としてプロトコルバッファーを簡単に使用できるとは思いません。すべてのRPCコードはこれらの定義から生成されており、再定義することができます Log 任意のオブジェクトを取得する方法(たとえば、プロトコルバッファオブジェクト)が、これは上記と同じくらい難しいでしょう。

私の知る限り、Googleは分散ロギングシステムをオープンソースしていません。 チュクワ Yahoo/Hadoopからの選択肢の1つです。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top