API Return Values and Types

gistfile1.rst

classifier

• train ... PENDING

  • type: int -> bool?
  • value: size of data (list of tuple of label and datum) -> true?

• classify ... OK

  • type: list<list<estimate_result> >

• get_config ... OK

  • type: string

gistfile2.rst

common

• save ... OK

  • type: bool
  • value: true

• load ... OK

  • type: bool
  • value: true

• get_status ... OK

  • type: map<string, map<string, string> >

gistfile3.rst

regression

• train ... PENDING

  • type: int -> bool?
  • value: size of data (list of tuple of label and datum) -> true?

• estimate ... OK

  • type: list<float>

• get_config ... OK

  • type: string

gistfile4.rst

recommender

• clear_row ... NG

  • type(idl): bool
  • type(cpp): int => bool
  • value: 0 => true

• update_row ... NG

  • type(idl): bool
  • type(cpp): int => bool
  • value: 0 => true

• clear ... NG

  • type(idl): bool
  • type(cpp): int => bool
  • value: 0 => true

• complete_row_from_id ... OK

  • type: datum

• complete_row_from_data ... OK

  • type: datum

• similar_row_from_id ... OK

  • type: similar_result (list<tuple<string, float> >)

• similar_row_from_data ... OK

  • type: similar_result (list<tuple<string, float> >)

• decode_row ... OK

  • type: datum

• get_all_rows ... OK

  • type: list<string>

• similarity ... OK

  • type: float

• l2norm ... OK

  • type: float

• get_config ... OK

  • type: string

gistfile5.rst

stat

• push ... NG

  • type(idl): bool
  • type(cpp): int

• sum ... OK

  • type: double

• stddev ... OK

  • type: double

• max ... OK

  • type: double

• min ... OK

  • type: double

• entropy ... OK

  • type: double

• moment ... OK

  • type: double

• get_config ... OK

  • type: string

gistfile6.rst

graph

• create_node ... PENDING (see #173 )

  • type: string -> uint64_t?

• update_node ... NG

  • type: int => bool
  • value: 0 => true

• remove_node ... NG

  • type: int => bool
  • value: 0 => true

• create_edge ... NG

  • type(idl): ulong
  • type(cpp): int => uint64_t

• update_edge ... NG

  • type: int => bool
  • value: 0 => true

• remove_edge ... NG

  • type: int => bool
  • value: 0 => true

• centrality ... OK

  • type: double

• shortest_path ... OK

  • type: list<string>

• add_centrality_query ... OK

  • type: bool
  • value: true

• add_shortest_path_query ... OK

  • type: bool
  • value: true

• remove_centrality_query ... OK

  • type: bool
  • value: true

• remove_shortest_path_query ... OK

  • type: bool
  • value: true

• get_node ... OK

  • type: node_info

• get_edge ... OK

  • type: edge_info

• update_index ... NG

  • type: int => bool
  • value: 0 => true

• clear ... NG

  • type: int => bool
  • value: 0 => true

• create_node_here ... NG

  • type: int => bool
  • value: 0 => true
  • internal used ... not check return

• remove_global_node ... NG

  • type: int => bool
  • value: 0 => true
  • internal used ... not check return

• create_edge_here ... NG

  • type: int => bool
  • value: 0 => true
  • internal used ... not check return

gistfile7.rst

anomaly

• clear_row ... OK

  • type: bool
  • value: true

• add ... OK

  • type: tuple<string, float>

• update ... OK

  • type: float
  • internal used ... not check return

• clear ... OK

  • type: boo
  • value: true

• calc_score ... OK

  • type: float

• get_all_rows ... OK

  • type: list<string>

• get_config ... OK

  • type: string

For internal RPC methods (create_node_here etc), how do callers handle the error?

I think, error handling in RPC methods will not be changed.
Callers must catch the exception thrown as the current.

Does it make sense?

I understand.
I checked RPC methods that used internal.

update stat#push.