Major Objects: Difference between revisions

From Bitpost wiki
No edit summary
No edit summary
Line 22: Line 22:


* find object iterator by id and pass it to parent containter delete method
* find object iterator by id and pass it to parent containter delete method
            int64_t account_id;
    int64_t account_id;
            auto itba = p_user->findBrokerAccount(account_id);
    auto itba = p_user->findBrokerAccount(account_id);
            if (itba == p_user->accounts_.end() )
    if (itba == p_user->accounts_.end() )
                return;
        return;
            p_user->deleteBrokerAccount(itba);
    p_user->deleteBrokerAccount(itba);
* container delete method passes object ref to Datastore method, deletes from memory, removes from container
* container delete method passes object ref to Datastore method, deletes from memory, removes from container
  bool AppUser::deleteBrokerAccount(AccountIt itba)
  bool AppUser::deleteBrokerAccount(AccountIt itba)

Revision as of 16:31, 5 February 2017

Overview

  • Major Objects
    • Use Major Objects for fast in-memory handling of large amount of data that is thread-safe but must be persisted
    • We must support complex objects with simple keys, crud, and fast lookup by multiple keys.
    • Our most useful containers are vector, set (key in object) and map (<key,value> pair). Set can give us almost every positive feature, when used to store the PersistentIDObject class.
    • Use an unordered_set of const pointers to objects derived from PersistentIDObject
    • The default container should index by db_id primary key
    • Always use the db_id for foreign keys
    • Other containers can be created with alternate keys using object members; just define new hash functions.
  • PersistentIDObject
    • Add a dirty flag to all objects, set to true on any change that must be persisted
    • Use an internal in-memory counter to generate the next db_id for a newly created object
    • This means that when creating new objects, there is NO NEED to access db, VERY IMPORTANT!
    • Use delayed-write tactics to write all dirty objects on idle time
  • Memory Model
    • Use a Datastore manager (aka "MemoryModel") to hold sets
    • It can look up objects by any key, and strip away const to return a mutable object. NOTE that the user must not damage the key values!
    • Derive a class from the memory model for persistence; it can use any persistence method (local, remote, sql, nosql, etc.).
    • Make sure that the base MemoryModel class is concrete not abstract, thread-safe and self-contained; this makes parallel calculations trivial, helps scalability, etc.

Delete pattern

  • find object iterator by id and pass it to parent containter delete method
   int64_t account_id;
   auto itba = p_user->findBrokerAccount(account_id);
   if (itba == p_user->accounts_.end() )
       return;
   p_user->deleteBrokerAccount(itba);
  • container delete method passes object ref to Datastore method, deletes from memory, removes from container
bool AppUser::deleteBrokerAccount(AccountIt itba)
{
    BrokerAccount& ba = **itba;
    g_p_local->deleteBrokerAccount(ba);     // delete from db
    delete &ba;                             // delete from memory
    accounts_.erase(itba);                  // erase from container
}
  • Datastore method deletes from db