You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »


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)

Class structure siagram


  • db_entry class represents data accessible through Access Layer 
  • hdc_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
al_entry constructor
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

al_entry create/open/close
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

IDS GET
def get(self, idsName, occurrence = 0) # idsName (e.g. 'equilibrium')
	return ids

1.4.2. IDS put

IDS PUT
def put(self, ids, occurrence = 0)

1.4.3. IDS putSlice

IDS PUT
def put_slice(self, ids, occurrence = 0)

1.4.4. IDS getSlice

IDS GET
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_data(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:

(plus) Can be achieved without big effort, as content of IDS class will not change (a lot)

(plus) All 'old' scripts will work - no modifications needed →  users are happy (smile)

(minus) 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.

(minus) All unwanted, messy methods operating on context stored (setCtx, etc)  must be kept 



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):









  • No labels