OK、これは非常に汚い回避策ですが、それでもうまくいきます。私はまだ IBM サポートが「標準的な方法」で私に戻ってくるのを待っています (これが存在するかどうかは疑問ですが):
まず、ヘッダーファイルのパスを定義します
HeaderFilePath = '/data/column_headers.tsv';
次に、ヘッダー ファイルを読み取ります。出力は配列です。
HeaderFile = localRead(del(location=HeaderFilePath, delimiter = "\t"));
arrayToRecord
ここで、次のステップで使用するために、HeaderFile 配列と同じ長さの 2 つの配列を作成します。1 つだけでなく 2 つを作成する理由は、後で明らかになります。
val_array = HeaderFile -> expand -> transform 'some string';
val_array2 = HeaderFile -> expand -> transform 'some other string';
アイデアは、データと同じスキーマを持つ人工レコード schema_record を構築し、 を介してスキーマを取得するschemaof
ことです。これは、データ ファイルを読み取るためのスキーマ入力として使用できます。このために使用できます
schema_record = arrayToRecord(HeaderFile -> expand,val_array)
問題:
a) をschemaof(schema_record)
返しますschema { * }?
。これは、スキーマが (一見) 実体化されたデータからしか推測できないためschema_record := arrayToRecord(HeaderFile -> expand,val_array)
です。
b) 今、 usingschemaof(schema_record)
はスキーマを返します。どっちがいい。ただし、スキーマ関数がこのようなことを行う理由はわかりませんが、スキーマ レコード"header1": @{const: "some string", fixed: 11} string
は、期待される ではなく、次のようになります"header1": string
。したがって、この「スキーマ」はほとんど役に立ちません。@{}
さらに悪いことに、仕様を削除できるように、そのスキーマ オブジェクトを操作する方法がないようです。
elementsOf
回避策:スキーマの配列の要素のスキーマを返すfunction を使用します。意味:
elementsOf([schemaof({a:1,b:3}),{a:1,b:3}]);
>> schema {"a":@{const: 1, fixed: 1} long, "b":@{const: 3, fixed: 1} long}.
ただし、「const」レコードと「fixed」レコードが異なるスキーマを使用すると、強制的elementsOf
に「生の」スキーマ (@{} なし) にフォールバックします。
elementsOf([schemaof({a:1,b:3}),{a:45,b:32}])
>> schema {"a": long, "b": long}.
これは、私が望むものを達成するために使用する「汚い回避策」です。(そして、これはすべて、スキーマとは何かについての非常に奇妙な理解によるものです...)
schema_array := [arrayToRecord(HeaderFile -> expand, val_array),arrayToRecord(HeaderFile -> expand, val_array2)];
DataSchema := elementsOf(schemaof(schema_array));
Data = read(lines(location='/data/data.tsv')) -> transform catch(delToJson($,
{"schema": DataSchema, "delimiter": "\t"}), {"errThresh": 99999999999},$);