Class MaapiCursor
For example if we have:
module mtest { namespace "http://tail-f.com/test/mtest/1.0"; prefix mtest; import ietf-inet-types { prefix inet; } import tailf-common { prefix tailf; } container mtest { container servers { list server { key name; max-elements 64; leaf name { type string; } leaf ip { type inet:host; mandatory true; } leaf port { type inet:port-number; default 80; } list interface { key name; max-elements 8; leaf name { type string; } leaf mtu { type int64; default 1500; } } } } } }
We can have the following Java code which iterates over all 'server' instances.
A cursor can also be created with an XPath filter:MaapiCursor c; ConfKey x; c = maapi.newCursor(th, "/mtest:mtest/servers/server"); x = maapi.getNext(c); while (x != null) { // do something x = maapi.getNext(c); }
MaapiCursor c = maapi.newCursorWithFilter(th, "starts-with(ip, \"10.\") and port > 8000", "/mtest:mtest/servers/server");
- See Also:
-
Method Summary
Modifier and TypeMethodDescriptionvoid
destroy()
Destroy the cursor on the server side.Return the XPath filter for this cursor, or null if there is none.int
getId()
getPath()
getPrev()
Return the name of the specified secondary index (if any).int
getTid()
void
setPrev
(ConfEObject prev) void
setSecondaryIndex
(String idx) Makes it possible to use a secondary index for the getNext calls.toString()
-
Method Details
-
getPrev
-
getPath
-
getTid
public int getTid() -
getId
public int getId() -
setPrev
-
setSecondaryIndex
Makes it possible to use a secondary index for the getNext calls.- Parameters:
idx
- Secondary index name
-
getSecondaryIndex
Return the name of the specified secondary index (if any). -
toString
-
getFilter
Return the XPath filter for this cursor, or null if there is none.- Returns:
- XPath filter for this cursor
-
destroy
public void destroy()Destroy the cursor on the server side.
There is normally no need to call this method. Only call it if the use pattern below feels familiar.
If iteration is ended before all results have been fetched the cursor will still be held on to on the server side since it cannot know that we are done using the cursor.
The cursor will be cleaned up on the server side when the transaction is finished or the MaapiCursor is garbage collected.
But, if the transaction is kept open and we create new cursors over and over again or perhaps keep them in a list, preventing them from being garbage collected, they will still be present on the server side if not iterated to the end, effectively creating a resource leak.
Calling this function explicitly cleans up resources on the server.
-