qme.main.database package¶

Submodules¶

qme.main.database.base module¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

class qme.main.database.base.Database[source]¶

Bases: object

A qme database holds common functions to represent tasks, and results. This is literally the base of the database, so it holds common shared functions to generate a task id or similar. The child classes (the specific database types) should have an init functions that ensures connection or creation of folders is possible.

add_task(executor)[source]¶: Create a filesystem task based on an executor type. The executor controls what data is exported and the uid, the task object just handles saving it.

clear()[source]¶: clear (delete) all tasks.

database = 'notimplemented'¶

delete_executor(name)[source]¶: delete all tasks for an executor, based on executor’s name (str).

delete_task(taskid)[source]¶: delete a task based on a specific task id. All task ids must be in the format of <taskid>-<uid> without extra dashes so we can reliably split based on the first dash.

get_task(taskid=None)[source]¶: Get a task based on a taskid. Exits on error if doesn’t exist. If a task id is not provided, get the last run task.

iter_executors(fullpath=False)[source]¶: list executors based on the subfolders in the base database folder.

list_tasks(name=None)[source]¶

list tasks associated with an executor, or all tasks.

Arguments: - executor (str) : the executor type. If not provided, list all

search(query)[source]¶: search is only available to non-filesystem databases

update_task(executor, updates=None)[source]¶: update a task with a json dictionary.

qme.main.database.filesystem module¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

class qme.main.database.filesystem.FileSystemDatabase(config_dir, config=None, **kwargs)[source]¶

Bases: qme.main.database.base.Database

A FileSystemDatabase writes raw json to files at $HOME/.qme/database This is the default flat database for qme, and on init we ensure that the database folder is created in QME_HOME.

add_task(executor)[source]¶: Create a filesystem task based on an executor type. The executor controls what data is exported and the uid, the task object just handles saving it.

clear()[source]¶: clear (delete) all tasks.

create_database(config_dir)[source]¶: Create the database. The parent folder must exist.

database = 'filesystem'¶

delete_executor(name)[source]¶: delete all tasks for an executor, based on executor’s name (str).

delete_task(taskid)[source]¶: delete a task based on a specific task id. All task ids must be in the format of <taskid>-<uid> without extra dashes so we can reliably split based on the first dash.

get_task(taskid=None)[source]¶: Get a task based on a taskid. Exits on error if doesn’t exist. If a task id is not provided, get the last run task.

iter_executors(fullpath=False)[source]¶: list executors based on the subfolders in the base database folder.

list_tasks(name=None)[source]¶: list tasks, either under a particular executor name (if provided) or just the executors. This returns tasks in rows to be printed (or otherwise parsed).

update_task(executor, updates=None)[source]¶: update a task with a json dictionary.

class qme.main.database.filesystem.FileSystemTask(executor, data_base, exists=False)[source]¶

Bases: object

A Filesystem Task can take a task id, determine if the task exists, and then interact with the data. If the task is instantiated without a taskid it is assumed to not exist yet, otherwise it must already exist.

create(should_exist=False)[source]¶: create the filename if it doesn’t exist, otherwise if it should (and does not) exit on error.

property executor_dir¶

export()[source]¶: wrapper to expose the executor.export function

property filename¶

load()[source]¶: Given a task, load data from filename.

run_action(name, **kwargs)[source]¶: Run an action, meaning running the executor’s run_action but providing data from the database.

save()[source]¶: Save a json object to the task.

summary()[source]¶

update(updates=None)[source]¶: Update a data file. This means reading, updating, and writing.

qme.main.database.models module¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

class qme.main.database.models.Task(taskid=None, executor=None, command=None)[source]¶

Bases: sqlalchemy.ext.declarative.api.Base

An executor task. The id is prefixed with the executor type, and must be unique.

command¶

data¶

executor_name¶

export()[source]¶: Export removes the outer wrapper, and just returns the data

load()[source]¶: loading a task means exporting as json

run_action(name, **kwargs)[source]¶: Run an action, meaning that we prepare data to it, and then run the self.executor.run_action(name, data) function.

summary()[source]¶

taskid¶

timestamp¶

qme.main.database.relational module¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

class qme.main.database.relational.RelationalDatabase(config_dir, config=None, **kwargs)[source]¶

Bases: qme.main.database.base.Database

A RelationalDatabase is a more robust relational datbase (to sqlite). Since the global database property can be any of postgresql, mysql+pysq;, it is defined on init. The sqlite database also uses this class, but defines a custom init function to handle the $HOME/.qme/qme.db file.

add_task(executor)[source]¶: Create a new task based on an executor type. The executor controls what data is exported and the uid, the task object just handles saving it.

clear()[source]¶: clear (delete) all tasks. This could be improved to cascade instead.

create_database()[source]¶: create the databsae based on the string, whether it’s relational or sqlite. self.db must be defined.

delete_executor(name)[source]¶: delete all tasks for an executor, based on executor’s name (str).

delete_task(taskid)[source]¶: delete a task based on a specific task id. All task ids must be in the format of <taskid>-<uid> without extra dashes so we can reliably split based on the first dash.

get_task(taskid=None)[source]¶: Get a task based on a taskid. Exits on error if doesn’t exist. If a task id is not provided, get the last run task.

iter_executors(fullpath=False)[source]¶: list executors based on the subfolders in the base database folder.

list_tasks(name=None)[source]¶: list tasks, either under a particular executor name (if provided) or just the executors. This returns tasks in rows to be printed (or otherwise parsed).

search(query)[source]¶: Search across the database for a particular query.

update_task(executor, updates=None)[source]¶: update a task with a json dictionary.

qme.main.database.sqlite module¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

class qme.main.database.sqlite.SqliteDatabase(config_dir, config=None, **kwargs)[source]¶

Bases: qme.main.database.relational.RelationalDatabase

A SqliteDatabase writes to a qme.db file in $HOME/.qme. This is the suggested database backend for QueueMe, as it doesn’t require anything beyond a filesystem and still allows for relational type queries.

database = 'sqlite'¶

Module contents¶

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

qme.main.database.init_db(database, config_dir=None, database_string='', config=None)[source]¶: Initialize the database, meaning a base client and appropriate functions to save, or generate a unique ID based on the backend being used. Each client has it’s own init to check for a connection (or filesystem path existence) and then functions to interact with entities.