Crate tugraph

Know issues

Memory leak

TuGraph use a smart pointer type(GCRefCountedPtr<T>) and its wingman scoped reference(ScopedRef<T>) to manage long-living objects which have few construct/destruct and a lot of references. If the last GCRefCountedPtr is destructed but with some ScopedRefs alive, the underlying T* deallocation task will be sent into TimedTaskScheduler. If TimedTaskScheduler runs long enough, the underlying T* will be deallocated(GC). However, TimedTaskScheduler is a static singleton mananger, its destructor will be called when the program is going to shutdown, make some underlying T* deallocation task cancelled and leave some T* leak. It is the root cause to memory leak.

What’s worse, there is no api to wait until all tasks in TimedTaskScheduler to be finished in order to make sure all T* are deallocated.

Modules

• cursor
  The core data read/write types which allow you move back and forth in graph.
• db
  Manages each Graph instance with access controlled manager Galaxy.
• field
  All types describe the attributes of graph element field.
• index
  Index specification about the index built on vertex/edge.
• role_info
• txn
  TuGraph operations happen in transactions. A transaction is sequence of operations that is carried out atomically on the Graph. TuGraph transactions provides full ACID guarantees.
• types
• user_info

Structs

• Error
  Error contains the message from what() yield by C++ std::exception

Enums

• ErrorKind
  ErrorKind ports all exceptions from lgraph_exceptions.h

Type Definitions

• Result