The following data types are used in the functions below:
-
index()
-
oid() = [byte()]
-
key_types = type_spec() | {type_spec(), type_spec(), ...}
-
type_spec() = fix_string | string | integer
-
key() = key_spec() | {key_spec(), key_spec(), ...}
-
key_spec() = string() | integer()
The index() type denotes an snmp index structure.
The oid() type is used to represent an ASN.1 OBJECT IDENTIFIER.
The key_types() type is used when creating the index structure, and the key() type is used when inserting and deleting items from the structure.
The key_types() type defines the types of the SNMP INDEX columns for the table. If the table has one single INDEX column, this type should be a single atom, but if the table has multiple INDEX columns, it should be a tuple with atoms.
If the INDEX column is of type INTEGER, or derived from INTEGER, the corresponding type should be integer. If it is a variable length type (e.g. OBJECT IDENTIFIER, OCTET STRING), the corresponding type should be string. Finally, if the type is of variable length, but with a fixed size restriction (e.g. IpAddress), the corresponding type should be fix_string.
For example, if the SNMP table has two INDEX columns, the first one an OCTET STRING with size 2, and the second one an OBJECT IDENTIFIER, the corresponding key_types parameter would be {fix_string, string}.
The key() type correlates to the key_types() type. If the key_types() is a single atom, the corresponding key() is a single type as well, but if the key_types() is a tuple, key must be a tuple of the same size.
In the example above, valid keys could be {"hi", "mom"} and {"no", "thanks"}, whereas "hi", {"hi", 42} and {"hello", "there"} would be invalid.
Warning
All API functions that update the index return a NewIndex term. This is for backward compatibility with a previous implementation that used a B+ tree written purely in Erlang for the index. The NewIndex return value can now be ignored. The return value is now the unchanged table identifier for the ets table.
The implementation using ets tables introduces a semantic incompatibility with older implementations. In those older implementations, using pure Erlang terms, the index was garbage collected like any other Erlang term and did not have to be deleted when discarded. An ets table is deleted only when the process creating it explicitly deletes it or when the creating process terminates.
A new interface delete/1 is now added to handle the case when a process wants to discard an index table (i.e. to build a completely new). Any application using transient snmp indexes has to be modified to handle this.
As an snmp adaption usually keeps the index for the whole of the systems lifetime, this is rarely a problem.