Introduced changes should work in parallel with existing API (unless it proves impossible)
'Old' methods and classes will be marked as deprecated
1. DB_ENTRY
1.1. Class structure:
Class keeps information about one, particular database entry (eg. pulse-file, HDC container, SQL-database, etc etc)
db_entry
class represents data accessible through Access Layerhdc_entry
,sql_entry
are examples of classes that represents IMAS data entry accessible via other mechanisms than AL (if they will be implemented in future)imas_entry
a parent class for all??_entry
classes. It will be implemented in future if any other mechanism of accessing data than AL will be used. Could be empty...
THIS PAGE FOCUSES ON DESIGN OF DB_ENTRY AND IDS CLASSES ONLY!
1.2. Definition (constructor)
DB Entry is defined by:
- backend_id - MDSPLUS_BACKEND, MEMORY_BACKEND, ASCII_BACKEND - mandatory -
- db name - eg.
test
- mandatory - shot - mandatory
- run - mandatory
- user name - eg.
g2bpalak
- optional - if None → $USER - data version - e.g. 3 - optional - currently not used, we should keep it as it will point us to a proper dir in imasdb structure, when we develop versions 4,5, etc - if None → 3
def __init__(self, backend_id, db_name, shot, run, user_name = None, data_version = 3) if userName is None: user = $USER
Additional "URI-based" constructor will be added in future...
1.3. Create/open/close
All parameters that defines db_entry
are set in constructor, so create, open, close
will have no arguments
def create(self, options = None) def open(self, options = None) def close(self, options = None) options - additional options (possibly backend specific)
1.4. IDS storing /reading
1.4.1. IDS get
def get(self, idsName, occurrence = 0) # idsName (e.g. 'equilibrium') ENUM ? wallObj = initialize_ids_obj('wall') wallObj.put(self(db_entry)) return wallObj
1.4.2. IDS put
def put(self, ids, occurrence = 0)
1.4.3. IDS putSlice
def put_slice(self, ids, occurrence = 0)
1.4.4. IDS getSlice
def get_slice(self, ids_name, time_requested, interpolation_method, occurrence=0): # idsName (e.g. 'equilibrium') return ids
1.5. Any other method is needed to ba added to db_entry class?
def delete(self, ids_name, occurrence=0):
2. IDS superclass
Parent class for all classes representing particular IDSes.
2.1. Class methods (aka "static")
def get_ids(cls, ids_name):
3. IDS class
To be backward compatible or not to be backward compatible, that is the question!
Backward compatibility, understood as possibility of using 'old' and 'new' approach at the same time:
Can be achieved without big effort, as content of IDS class will not change (a lot)
All 'old' scripts will work - no modifications needed → users are happy
Currently all methods use context kept in IDS that was a reason of many problems. New API is designed to overcome this issue. Keeping compatibility means that methods still have to be able to use context stored in IDS that is error prone.
All unwanted, messy methods operating on context stored (setCtx, etc) must be kept
Compatibility can be also ensured by introducing new names of methods - putSlice
vs put_slice
3.1. Class methods (aka "static")
def get_max_occurrences(cls): def read_time_mode(self, ctx): def read_time(self, ctx):
3.2. IDS storing / reading
db_entry
is used to provide explicitly context to methods. This parameter should be mandatory, but is optional to keep compatibility....
def put(self, occurrence=0, db_entry=None): def get(self, occurrence=0, db_entry=None): def putSlice(self, occurrence=0, db_entry=None): def getSlice(self, time_requested, interpolation_method, occurrence=0, db_entry=None):
3.3. Additional methods
def copy_values(self, ids): def delete_data(self, occurrence=0, db_entry=None ): def partial_get(self, dataPath, occurrence=0, db_entry=None): def get_field(self, dataPath, occurrence=0, db_entry=None):
3.4. "Messy" methods
... that are not in line with proposed design but they must be kept to ensure backward compatibility.
def setPulseCtx(self, ctx): def getPulseCtx(self):