next up previous index
Next: dict_storage Up: The opus_core Opus Package Previous: Using InteractionDataset   Index


Data Storage

One of the design elements of Opus is to allow users to choose alternative data storage methods depending on their needs, while keeping a consistent internal representation of data used by the system. Currently Opus classes exist for reading and writing data in Random Access Memory (RAM), to database tables, Tab-delimited ASCII files, and binary files. Other storage methods can be added as the need arises.

The generic class that supports data storage is called Storage. Every class that we describe below derives from this class and implements the storage interface. All such classes therefore provide the following methods:

load_table(): Loads the data stored in the data repository and returns it as a dicionary, where each key represents an attribute (column) of the table. The only required argument is table_name. Optional arguments include column_names (a list of columns that you want loaded; the default is to load all) and lowercase (for forcing all names column names to lowercase).

write_table(): Writes data out to the respective storage. The two non-optional parameters are table_name and table_data, the former naming the table and the latter defining the data to be written. More specifically, the table_data argument should be a dictionary, where the keys represent a column and the values represent the data in those columns. This is the same format as that returned by the load_table() method. An optional parameter mode allows you to determine whether an existing table of the same name will either be overwritten or appended to with the new data. By default the table is overwritten.

get_storage_location(): Returns the location at which data is being stored for this storage object. In the case of storage locations that exist on disk, a file path is returned. In the case of a database, an OpusDatabase object will be returned.

get_column_names(): Takes a table_name as an argument and returns a list of attribute names that were found on the storage.

table_exists(): Takes a table_name as an argument and returns whether a table by that name exists at the respective storage location.

get_table_names(): Returns a list of all the names of tables that exist at the respective storage location.

Developer note: In order to be able to implement the storage interface, the new storage subclass must implement methods load_table, get_storage_location, write_table, and get_column_names.

The predefined storage classes in opus_core are dict_storage, csv_storage, tab_storage, sql_storage, flt_storage, and dbf_storage implemented in modules of the same name in opus_core.store. Their instances can be created using the method get_storage(type, storage_location,...) of class StorageFactory; type is the storage type (e.g. ``sql_storage'') and storage_location is either a location on disk or an OpusDatabase, depending on the type of storage being created. Other optional, storage-type specific arguments can also be passed in to the get_storage method. We now give a brief description of each available storage type, and how each may deviate from the above descriptions.



Subsections
next up previous index
Next: dict_storage Up: The opus_core Opus Package Previous: Using InteractionDataset   Index
info (at) urbansim.org