Ideas:
  • One DBManager per session of the DAQ.
  • DBManager with 3 interfaces: to TableSpace, to TStore and to Adapters

  • TableSpaces act as the transport from the DBManger to the Adapter level. Note: DBManager and TableSpace may be the same thing? Not from depoyment point of view?
  • Interface TableSpace-Adapter: should allow TableSpace to access to all data identified by a query:
        class Query {
            string Name;
            map<string,Serializable*> Parameters;
        }
    
    Name and parameters completely specify the interface for any TStore-wrapped SQL query.

  • Adapters: objects that know how to convert sets of xdata::Tables (QueryResults) into c++ high level objects. They should be able to run over a TableSpace.

  • Interface Adapters - DBManager: parameters exported to the DBManager info space, soap callback bounds. Note: what link beetween SOAP Callbacks and exported parameters?
        Class MyAdapter {
         public:
             MyAdapter() {
                  DBManager::bind("MyCcallBack",&MyCallback);
            }
        };
    
        MyAdapter myAdapter;
        myAdapter.exportParameters(theInfoSpace);
    
    
    * Adapters are aware of the database structure, or at least of the representation of data resulting from the tstore (i.e. the QueryResults).

-- PasqualeMusella - 10 Apr 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2007-04-12 - PasqualeMusella
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback