【GAS】「SpreadsheetApp.create を呼び出す権限がありません」を解決する

表題の通りです。
タイトルのエラーメッセージでググったところ、トリガーを設定し、解決されている方が多いようです。 しかし、当方の要件としては、トリガーで定期的に実行させる必要はなく、エラーメッセージは権限の問題なのでスコープを設定したかったので、appsscript.jsonでスコープを設定する方法を残します。

余談ですが、GUIから設定できるのかと思ったので、探してみたのですが、 ファイル -> プロジェクトのプロパティ -> スコープタブでは、権限が確認できるのみで変更はできなかったので、appsscript.jsonに以下を追加しました1。

{
  "oauthScopes": ["https://www.googleapis.com/auth/spreadsheets.readonly"],
}

なお、参照権限のみで十分であれば、https://www.googleapis.com/auth/spreadsheets.readonlyのようにreadonlyを付けましょう。

References

  1. 必要な箇所のみ記載して、前後は省略しています。↩

clasp runがローカルで実行されない

背景

Google Apps Scriptをローカルで開発するために、 Google製のCLIツールclaspを導入しました。
Google Drive上のプロジェクトとclasp pushやclasp pullで同期できてとても便利なのですが、 以下事象でハマったので記事に残します。

事象

  1. ローカルでコードを編集
  2. clasp pushする
  3. clasp run <function name>すると、2.でpushしたコードが実行されない

切り分けをしたところ

  • ブラウザ上のプロジェクトで見ると公開 - 実行可能APIとして導入...が2.で上げたバージョンになっていない

が原因のようでした。

解決方法

--devオプションをつければローカルで実行されます。

❯ clasp run --dev <function name>

References

protobufのNon-varintの互換性について

以前、Varintを64bitから32bitに変更したときの挙動を検証しました。

cipepser.hatenablog.com

上記記事の通りVarintは、下位32-bitを残して切り詰める結果でした。 今回は、Non-varintの互換性を検証します。

例によって、Language Guideを見てみると

fixed32 is compatible with sfixed32, and fixed64 with sfixed64.

と述べられています。

fixed32とsfixed32、fixed64とsfixed64のように同じ長さであれば、互換性があるようです。

実際、Protocol Buffers - Encodingのwire typesで以下のように定義されており、32bitと64bitでそもそもTypeが異なります。

Type Meaning Used For
0 Varint int32, int64, uint32, uint64, sint32, sint64, bool, enum
1 64-bit fixed64, sfixed64, double
2 Length-delimited string, bytes, embedded messages, packed repeated fields
3 Start group groups (deprecated)
4 End group groups (deprecated)
5 32-bit fixed32, sfixed32, float

.proto

今回は以下の.protoを使います。

syntax = "proto3";
package fixed;

message User {
  fixed32 id = 1;
}

idをfixed32、fixed64、sfixed32、sfixed64の4パターンで変化させて、検証します。

書き出し

書き出し用のコードは以下の通りです。 Idのvalueはbitがすべて1になる値で検証します(user.Idフィールドのコメントアウト参照)。

package main

import (
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/fixed"
    "github.com/golang/protobuf/proto"
    "fmt"
    // "math" // fixed32とfixed64のときのみ利用
)

func main() {
    user := &pb.User{
        //Id: math.MaxUint32, // fixed32のとき
        //Id: math.MaxUint64, // fixed64のとき
        Id: -1,  // sfixed32とsfixed64のとき
    }

    fmt.Printf("%x\n", user.Id)

    if err := write("./fixed/fixed32.bin", user); err != nil {
        log.Fatal(err)
    }
}

func write(file string, user *pb.User) error {
    out, err := proto.Marshal(user)
    if err != nil {
        return err
    }
    fmt.Printf("% x\n", out)
    if err := ioutil.WriteFile(file, out, 0644); err != nil {
        return err
    }
    return nil
}

出力ファイルfixed32.binの部分は、fixed32、fixed64、sfixed32、sfixed64ごとに別ファイルとして出力します。

読み込み

読み込み用のコードです。

package main

import (
    "fmt"
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/fixed"
    "github.com/golang/protobuf/proto"
)

func main() {
    if err := read("./fixed/fixed32.bin"); err != nil {
        log.Fatal(err)
    }
    if err := read("./fixed/fixed64.bin"); err != nil {
        log.Fatal(err)
    }
    if err := read("./fixed/sfixed32.bin"); err != nil {
        log.Fatal(err)
    }
    if err := read("./fixed/sfixed64.bin"); err != nil {
        log.Fatal(err)
    }
}

func read(file string) error {
    in, err := ioutil.ReadFile(file)
    if err != nil {
        return err
    }
    user := &pb.User{}

    if err := proto.Unmarshal(in, user); err != nil {
        return err
    }
    fmt.Printf("%d\n", user.Id)
    return nil

}

読み込みの前に、.protoのidをfixed32、fixed64、sfixed32、sfixed64で変化させて、protoc -I=fixed/ --go_out=fixed/ fixed.protoを実行しています。

結果

書き出し、読み込みを全パターンで行った結果は以下の通りです。
※表のレイアウトが崩れるため、4294967295(math.MaxUint32)と18446744073709551615(math.MaxUint64)をMaxUint32とMaxUint64で略記します。

正しく読み込めている（○）のは、書き出し/読み込みで同じ.protoを使ったパターンのみでした。

.proto(write時) 値(write) .proto(read時) 値(read) 結果
fixed32 MaxUint32 fixed32 MaxUint32 ○
fixed32 MaxUint32 fixed64 0 ×
fixed32 MaxUint32 sfixed32 -1 △
fixed32 MaxUint32 sfixed64 0 ×
fixed64 MaxUint64 fixed32 0 ×
fixed64 MaxUint64 fixed64 MaxUint64 ○
fixed64 MaxUint64 sfixed32 0 ×
fixed64 MaxUint64 sfixed64 -1 △
sfixed32 -1 fixed32 MaxUint32 △
sfixed32 -1 fixed64 0 ×
sfixed32 -1 sfixed32 -1 ○
sfixed32 -1 sfixed64 0 ×
sfixed64 -1 fixed32 0 ×
sfixed64 -1 fixed64 MaxUint64 △
sfixed64 -1 sfixed32 0 ×
sfixed64 -1 sfixed64 -1 ○

上記結果を見ると、 パースそのものに失敗して、値が0となった（×）ものと、 値は読み込めているものの元の値と異なる（△）もの があることがわかります。

よくよく見てみると×は32bitと64bitで長さが異なるもののみです。

Language Guideの

fixed32 is compatible with sfixed32, and fixed64 with sfixed64.

の通りですね。
しかし、同じ長さであればcompatibleなはずなのに△で元の値と変わってしまったものもあります。
もう少し深掘りするために、書き出したバイナリを表に加えてみます。(binary列)

proto(write時) 値(write) binary proto(read時) 値(read) 結果
fixed32 MaxUint32 0d ff ff ff ff fixed32 MaxUint32 ○
fixed32 MaxUint32 0d ff ff ff ff fixed64 0 ×(32bit vs 64bit)
fixed32 MaxUint32 0d ff ff ff ff sfixed32 -1 △
fixed32 MaxUint32 0d ff ff ff ff sfixed64 0 ×(32bit vs 64bit)
fixed64 math.MaxUint64 09 ff ff ff ff ff ff ff ff fixed32 0 ×(32bit vs 64bit)
fixed64 math.MaxUint64 09 ff ff ff ff ff ff ff ff fixed64 math.MaxUint64 ○
fixed64 math.MaxUint64 09 ff ff ff ff ff ff ff ff sfixed32 0 ×(32bit vs 64bit)
fixed64 math.MaxUint64 09 ff ff ff ff ff ff ff ff sfixed64 -1 △
sfixed32 -1 0d ff ff ff ff fixed32 MaxUint32 △
sfixed32 -1 0d ff ff ff ff fixed64 0 ×(32bit vs 64bit)
sfixed32 -1 0d ff ff ff ff sfixed32 -1 ○
sfixed32 -1 0d ff ff ff ff sfixed64 0 ×(32bit vs 64bit)
sfixed64 -1 09 ff ff ff ff ff ff ff ff fixed32 0 ×(32bit vs 64bit)
sfixed64 -1 09 ff ff ff ff ff ff ff ff fixed64 math.MaxUint64 △
sfixed64 -1 09 ff ff ff ff ff ff ff ff sfixed32 0 ×(32bit vs 64bit)
sfixed64 -1 09 ff ff ff ff ff ff ff ff sfixed64 -1 ○

まず、追加したbinary列の先頭の0dや09でkeyのfield_numberとwire_typeがわかります。
Protocol Buffers - Encodingに書いてあるとおり、keyは、(field_number << 3) | wire_typeでエンコードされます。

つまり、
0dは(1 << 3) | 5なので、type5(32-bit)のフィールド1(Id)であり、
09は(1 << 3) | 1なので、type5(64-bit)のフィールド1(Id)です。

その後に続くff...がvalue1です。

まとめ

以上から、×となった32bitと64bitは0dと09でそもそものwire_typeが異なり、パースに失敗し、defalut valueである0となったようです。

△となった箇所については、wire_typeが同じ(fixed32とsfixed32は0d、fixed64とsfixed64は09)ため、後続のバイナリをvalueとしてパースします。 パースする際に.protoが異なるため、書き込んだ値と違う値で解釈されてしまったわけです。 例えば、fixed32→sfixed32では、 fixed32としてMaxUint32(4294967295)を0xff ff ff ffとしてエンコードします。 しかし、sfixed32で0xff ff ff ffをパースすると-1として解釈されてしまいます。

パースに際してエラーが起きるわけではない2ので、正しく解釈できる範囲でcompatibleです。 上記の例(32bit)では、0x00 00 00 00〜0x07 ff ff ffです。 これを超えると、正数と2の補数で表現された負数が区別できないため、signed/unsignedで結果が異なります。

References

  1. 今回はffとなっているため区別しませんが、valueはホストバイトオーダーで書き込まれるようなので、リトルエンディアンになることが多いと思います。バイナリを読む際にはご注意ください。↩

  2. 処理系によって異なるかもしれません。今回検証したGoの範囲での結果です。↩

protobufで0 byteをデコードする

Language Guideに以下のようにフィールドに値がセットされていない場合はdefault valueが使われることが書かれています。

When a message is parsed, if the encoded message does not contain a particular singular element, the corresponding field in the parsed object is set to the default value for that field.

ということは何も書かれていない(0 byteの)バリナリをパースしようとすると、すべてのフィールドがdefault valueとなるはずなので試してみました。

パースする.proto

以下のような.protoを用意します。

syntax = "proto3";
package blank;

message User {
  int32 id = 1;
  string name = 2;
  fixed64 age = 3;
  Contact contact = 4;
}

message Contact {
  string phone = 1;
  string email = 2;
}

protocします。

❯ protoc -I=blank/ --go_out=blank/ blank.proto

パースする

0 byteの入力としてin := []byte{}を使います。 inをUserにパースし、各フィールドを標準出力して、default valueになっているか確認します。

package main

import (
    "fmt"
    "log"

    pb "github.com/cipepser/protobuf-sample/blank"
    "github.com/golang/protobuf/proto"
)

func main() {
    user := &pb.User{}
    in := []byte{}

    if err := proto.Unmarshal(in, user); err != nil {
        log.Fatal(err)
    }

    fmt.Println("ID: ", user.Id)
    fmt.Println("Name: ", user.Name)
    fmt.Println("Age: ", user.Age)
    fmt.Println("Contact: ", user.Contact)
 }

結果

実行結果は以下の通りです。

❯ go run BlankRead.go
ID:  0
Name:
Age:  0
Contact:  <nil>

ちゃんとdefault valueでパースできました。
ちなみに、上記の通りuser.Contactはnilがdefault valueのため、PhoneやEmailにアクセスしようとするとpanicになります。

fmt.Println("Phone: ", user.Contact.Phone)
// panic: runtime error: invalid memory address or nil pointer dereference

References

Golangで出力したprotobufバイナリをRustで読み込む

ここ三回くらいprotobufの記事を書いてきましたが、Goばかりだったので、Rustで読み込んでみました。

事前準備：Goでバイナリを出力する

user.protoを以下のように定義します。

syntax = "proto3";
package user;

message User {
  string name = 1;
  int32 age = 2;
}

Go用にprotocする

❯ protoc -I=./ --go_out=./ user.proto

user.pb.goが生成されます。

バイナリを書き出す

以下のユーザをprotobufのバイナリとしてgo_user.binを書き出します。

フィールド 値
Name Alice
Age 20

出力用のコードは以下の通りです。

package main

import (
    "fmt"
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/rust-protobuf-example/user"
    "github.com/golang/protobuf/proto"
)

func main() {
    p := &pb.User{
        Name: "Alice",
        Age:  20,
    }

    out, err := proto.Marshal(p)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(out)
    if err := ioutil.WriteFile("./go_user.bin", out, 0644); err != nil {
        log.Fatalln("Failed to write:", err)
    }
}

Rustで読み込む

いよいよ本題のRustです。

Cargo.tomlの設定

Rustでprotobufを扱うためにrust-protobufを使います。 Cargo.tomlのdependenciesにprotobufを記載します。 READMEにも書いてありますが、bytesクレートを使っているのでbytesも記載します。

[dependencies]
protobuf = { version = "~2.0", features = ["with-bytes"] }

2019/08/03追記
stepancheg/rust-protobuf: Rust implementation of Google protocol buffersに、version2未満がサポート対象外になったと書いてあるので、追記現在では以下のように記載します。

[dependencies]
protobuf = { version = "2", features = ["with-bytes"] }

Rust用にprotocする

user.protoは、Goでprotocしたときと同じものです。

❯ protoc --rust_out src/ user.proto

以下のようなメッセージが出る場合は、protoc-gen-rustがないのでインストールしましょう。

protoc-gen-rust: program not found or is not executable
--rust_out: protoc-gen-rust: Plugin failed with status code 1

以下でインストール出来ます（Cargo.tomlに書いてもいいのかも）。

❯ cargo install protobuf-codegen

protocがうまくいけば、src/user.rsがgenerateされます。

読み込む

ファイル読み込み、User型にmerge、標準出力するまでのコードは以下のとおりです。

extern crate protobuf;

mod user;

use user::User;
use std::fs::File;
use std::io::{BufReader};
use protobuf::{CodedInputStream, Message};

fn main() {
    let file = File::open("./go_user.bin").expect("fail to open file");
    let mut buffered_reader = BufReader::new(file);
    let mut cis = CodedInputStream::from_buffered_reader(&mut buffered_reader);

    let mut u = User::new();
    u.merge_from(&mut cis).expect("fail to merge");

    println!("Name: {}", u.get_name());
    println!("Age: {}", u.get_age());
}

実行すると、以下のようにNameとAgeが読み取れていることがわかります。

/usr/local/bin/cargo run --color=always --package rust-protobuf-example --bin rust-protobuf-example
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/rust-protobuf-example`
Name: Alice
Age: 20

Process finished with exit code 0

References

protobufのVarintを64bitから32bitに変更したときの挙動

protobufのVarintはProtocol Buffers - Encodingで定義されるように、32-bit(int32, uint32, sint32)や64-bit(int64, uint64, sint64)のどちらも含まれています。 Varintのエンコーディングは、その値によってbyte長が変わりますが（負数は-1のような小さい数でも最上位bitが1になりエンコードした結果長くなってしまうので非推奨となっている）、64-bitでエンコードされた値を32-bitで読み込んだ場合、どのような動作になるのか気になったので試してみました。

なお、Varintには、boolやenumも含まれていますが、 その変換については以下の記事で検証したのため、興味があればそちらをご覧ください。

cipepser.hatenablog.com

cipepser.hatenablog.com

結論から言うと仕様に、以下のように書いてあるので、処理系の実装依存と思われますが、Goで実際に試してみたメモとして残します。

If a number is parsed from the wire which doesn't fit in the corresponding type, you will get the same effect as if you had cast the number to that type in C++ (e.g. if a 64-bit number is read as an int32, it will be truncated to 32 bits).

環境

❯ go version
go version go1.10.3 darwin/amd64

❯ protoc --version
libprotoc 3.6.0

検証(uint64 -> uint32)

uint64でmath.MaxUint32よりも大きくなる値をuint32で読み込んでみて動作を検証します。
（最後にintも検証結果も記載しますが、コードも含めてすべて記載すると長いのでuintのみとします）

今回の例では、読み込む値をUserがもつIdとし、以下のように.protoを定義します。

syntax = "proto3";
package max;

message User {
  uint64 id = 1;
}

書き出し

次に書き出し用のコードです。 math.MaxUint32よりも大きくなる値を0b1111111111111111111111111111111100000000000000000000000000000000とします。 これは前半32-bitが1で後半32-bitが0となる値で、math.MaxUint64 - math.MaxUint32で生成します。この数字を使うことでuint32で読み込んだときに後半32-bitだけに切り詰められる(0になる)のか、math.MaxUint32より大きくオーバーフローしてしまうのか確認します。

// MaxWrite.go
package main

import (
    "io/ioutil"
    "log"
    "math"

    pb "github.com/cipepser/protobuf-sample/max"
    "github.com/golang/protobuf/proto"
)

func main() {
    user := &pb.User{
        Id: math.MaxUint64 - math.MaxUint32,
    }

    if err := write("./max/uint.bin", user); err != nil {
        log.Fatal(err)
    }
}

func write(file string, user *pb.User) error {
    out, err := proto.Marshal(user)
    if err != nil {
        return err
    }
    if err := ioutil.WriteFile(file, out, 0644); err != nil {
        return err
    }
    return nil
}

読み込み

読み込み用のコードです。

// MaxRead.go
package main

import (
    "fmt"
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/max"
    "github.com/golang/protobuf/proto"
)

func main() {
    if err := read("./max/uint.bin"); err != nil {
        log.Fatal(err)
    }
}

func read(file string) error {
    in, err := ioutil.ReadFile(file)
    if err != nil {
        return err
    }
    user := &pb.User{}

    if err := proto.Unmarshal(in, user); err != nil {
        return err
    }
    fmt.Printf("0d%d\n0b%b\n", user.Id, user.Id)
    return nil
}

10進数(0d)と2進数(0b)でuser.Idを標準出力します。 試しに実行してみると、以下のように正常にデコードできていることがわかります。

❯ go run MaxRead.go
0d18446744069414584320
0b1111111111111111111111111111111100000000000000000000000000000000

.protoをuint32に変更する

では、uint32に変更して、上記で出力したuint64のバイナリを読み込みましょう。

syntax = "proto3";
package max;

message User {
  uint32 id = 1;
}

protocしてから読み込みます。

❯ go run MaxRead.go
0d0
0b0

0になったので、後半32-bitだけに切り詰められたようです。

結果

同様の検証をint64 -> int32、sint64 -> sint32でもやってみた結果も含めて、まとめると以下のようになりました。

検証パターン(.proto) 読み込む値 64-bitのまま読み込み 32-bitにして読み込み
uint64 -> uint32 math.MaxUint64 - math.MaxUint32 0d18446744069414584320
0b1111111111111111111111111111111100000000000000000000000000000000 		0d0
0b0
int64 -> int32 math.MaxInt64 - math.MaxInt32 - 1 <<31 0d9223372032559808512
0b111111111111111111111111111111100000000000000000000000000000000 		0d0
0b0

結果、uintでもintでも同様に後半32-bitに切り詰められる結果となりました。

余談

intのほうで1 << 31を引いているのですが、最初、math.MaxInt64 - math.MaxInt32としていました。 符号付き整数なので、これだと下位31-bitしか0にできず、この値をint32として読み込むと以下のようになってしまいます。

0d-2147483648
0b-10000000000000000000000000000000

検証としては、下位32-bitを残して切り詰める結果から相違ないので、参考としてこの結果も載せておきます。

ちなみにmath.MinInt64 - math.MinInt32を読み書きしても上記と同じ結果になります(2進数で見たときに同じ値になるので)。

References

protobufのenumの互換性について

前回記事の続きです。 前回は、boolだったフィールドをint32に変換した場合に互換性が保たれるのかを見ました。 実用上はint32にするより、enumにすることが多いと思うので、今回はenumでの互換性をみていきます。

enumについては、Language GuideのEnumerationsに、以下のように書いてあります。

Enumerator constants must be in the range of a 32-bit integer. Since enum values use varint encoding on the wire, negative values are inefficient and thus not recommended.

これを見るとenumは、同じくvarintとしてencodingされるint32と互換性がありそうです。 ただ、個人的に気になった点として、Language GuideのUpdating A Message Typeに以下のような二文があることです。

int32, uint32, int64, uint64, and bool are all compatible

enum is compatible with int32, uint32, int64, and uint64

boolとenumで、わざわざ文を2つにわけていたので気になって調べることにしました（結論、あまり分けている意味はなさそうでしたが）。

今回確認したいのは以下2点です。

  • enumとboolは互換性があるのか
  • .protoで未定義のenumフィールドをパースした場合の挙動

enumとboolは互換性があるのか

では、早速1つ目を確認していきましょう。 enum -> boolとbool -> enumの両方向に変えてみたときの挙動を順番にみていきます。 例題は、前回記事と同じUserのtypeを変えるものとします。

enum -> bool

enumで書き出す

まずenumで.protoを以下のように定義します。

syntax = "proto3";
package enum;

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
  }
  Type type = 1;
}

前回同様、ファイルに書き出していきます。

// EnumWrite.go
package main

import (
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/enum"
    "github.com/golang/protobuf/proto"
)

func main() {
    normal := &pb.User{
        Type: pb.User_NORMAL,
    }
    if err := write("./enum/normal.bin", normal); err != nil {
        log.Fatal(err)
    }

    premium := &pb.User{
        Type: pb.User_PREMIUM,
    }
    if err := write("./enum/premium.bin", premium); err != nil {
        log.Fatal(err)
    }
}

func write(file string, user *pb.User) error {
    out, err := proto.Marshal(user)
    if err != nil {
        return err
    }

    if err := ioutil.WriteFile(file, out, 0644); err != nil {
        return err
    }

    return nil
}

boolで読み込む

この.protoで読み込ます。

syntax = "proto3";
package enum;

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
  }
  bool type = 1;
}

読み込み用のコードは以下の通りです。

// EnumRead.go
package main

import (
    "fmt"
    "io/ioutil"
    "log"

    pb "github.com/cipepser/protobuf-sample/enum"
    "github.com/golang/protobuf/proto"
)

func main() {
    if err := read("./enum/normal.bin"); err != nil {
        log.Fatal(err)
    }
    if err := read("./enum/premium.bin"); err != nil {
        log.Fatal(err)
    }
}

func read(file string) error {
    in, err := ioutil.ReadFile(file)
    if err != nil {
        return err
    }
    user := &pb.User{}

    if err := proto.Unmarshal(in, user); err != nil {
        return err
    }
    fmt.Println(file, ": ", user.Type)
    return nil
}

読み込み結果は以下のようになりました。

❯ go run EnumRead.go
./enum/normal.bin :  false
./enum/premium.bin :  true

bool -> enum

次に逆方向も確認しましょう。 書き出し、読み出し用のコードは長くなるので差分のみ表にまとめます。

EnumWrite.goの差分です。

ユーザ ファイル名 pb.User.Type（前） pb.User.Type（後）
一般 normal02.bin pb.User_NORMAL false
プレミアム premium02.bin pb.User_PREMIUM true

EnumRead.goと上記表のファイル名のみの変更なので省略します。

boolで書き出す

.protoは以下の通りです。

syntax = "proto3";
package enum;

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
  }
  bool type = 1;
}

この.protoでEnumWrite.goを実行し、ファイルに書き出します。

enumで読み込む

.protoを以下のようにenumに変更し、boolで書き出したファイルを読み込みます。

syntax = "proto3";
package enum;

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
  }
  Type type = 1;
}

実行結果は以下の通りです。

❯ go run EnumRead.go
./enum/normal02.bin :  NORMAL
./enum/premium02.bin :  PREMIUM

結果

上記の結果をまとめると以下表のようになりました。

ユーザ enum -> bool bool -> enum
一般 false NORMAL
プレミアム true PREMIUM

確認したかったことの1つ目「enumとboolは互換性があるのか」は「互換性あり」ということが確認できました。

.protoで未定義のenumフィールドをパースした場合の挙動

続けて2つ目の疑問を解決していきましょう。

3種類のユーザ種別を定義する

変更前は、ユーザ種別typeを以下のようにenumで 3つ 定義します。

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
    GOLD = 2;
  }
  Type type = 1;
}

先程と同じく、書き出し、読み出しは以下の設定で行います。

ユーザ ファイル名 pb.User.Type
一般 normal03.bin pb.User_NORMAL
プレミアム premium03.bin pb.User_PREMIUM
ゴールド gold03.bin pb.User_GOLD

3種のまま読み込む

比較のため、.protoを変更せずにユーザ種別が3つのまま読み込んだ結果は以下となります。 当たり前ですが、正しく読み込めていますね。

❯ go run EnumRead.go
./enum/normal03.bin :  NORMAL
./enum/premium03.bin :  PREMIUM
./enum/gold03.bin :  GOLD

2種類にして読み込む

互換性を確認するためユーザ種別を 2つ に減らします。

syntax = "proto3";
package enum;

message User {
  enum Type {
    NORMAL = 0;
    PREMIUM = 1;
  }
  Type type = 1;
}

GOLDを削除しました。この.protoで読み込んだ結果は以下の通りです。

❯ go run EnumRead.go
./enum/normal03.bin :  NORMAL
./enum/premium03.bin :  PREMIUM
./enum/gold03.bin :  2

結果

上記の結果を表にまとめます。

ユーザ 変更前（3種） 変更後（2種）
一般 NORMAL NORMAL
プレミアム PREMIUM PREMIUM
ゴールド GOLD 2

2つ目の疑問「.protoで未定義のenumフィールドをパースした場合の挙動」の回答としては、エラーは起きず、Unmarshal()は正常に動作するものの、GOLDが2として出力される、でした。 enumの定義を知らないことを考えると妥当な挙動なように思えます。

検証後に気付いたのですが、Language GuideのEnumerationsに、以下のように書いてありました。

During deserialization, unrecognized enum values will be preserved in the message, though how this is represented when the message is deserialized is language-dependent. In languages that support open enum types with values outside the range of specified symbols, such as C++ and Go, the unknown enum value is simply stored as its underlying integer representation. In languages with closed enum types such as Java, a case in the enum is used to represent an unrecognized value, and the underlying integer can be accessed with special accessors. In either case, if the message is serialized the unrecognized value will still be serialized with the message.

未定義のenumの処理自体は、言語に依存するようで、今回のようにGoの場合は単純にint型の数値として認識されるそうです。

上記挙動を理解した上で利用することも考えられますが、あまりおすすめできる方法ではありません。そもそも今回のようなユーザ種別を減らすような変更は、「一度定義したmessage typeは変更しない」というprotobufの思想に反するので、基本的には削除しない方が良いでしょう。

References