l.s.d.i.IStoreSelector(Interface) : interface documentation

Part of lp.services.database.interfaces View In Hierarchy

Get a Storm store with a desired flavor.

Stores come in two flavors - MASTER_FLAVOR and SLAVE_FLAVOR.

The master is writable and up to date, but we should not use it whenever possible because there is only one master and we don't want it to be overloaded.

The slave is read only replica of the master and may lag behind the master. For many purposes such as serving unauthenticated web requests and generating reports this is fine. We can also have as many slave databases as we are prepared to pay for, so they will perform better because they are less loaded.

Method push Install an IDatabasePolicy as the default for this thread.
Method pop Uninstall the most recently pushed IDatabasePolicy from
Method get_current Return the currently installed IDatabasePolicy.
Method get Retrieve a Storm Store.
def push(dbpolicy):
Install an IDatabasePolicy as the default for this thread.
def pop():
Uninstall the most recently pushed IDatabasePolicy from this thread.

Returns the IDatabasePolicy removed.

def get_current():
Return the currently installed IDatabasePolicy.
def get(name, flavor):
Retrieve a Storm Store.

Results should not be shared between threads, as which store is returned for a given name or flavor can depend on thread state (eg. the HTTP request currently being handled).

If a SLAVE_FLAVOR is requested, the MASTER_FLAVOR may be returned anyway.

The DEFAULT_FLAVOR flavor may return either a master or slave depending on process state. Application code using the DEFAULT_FLAVOR flavor should assume they have a MASTER and that a higher level will catch the exception raised if an attempt is made to write changes to a read only store. DEFAULT_FLAVOR exists for backwards compatibility, and new code should explicitly state if they want a master or a slave.

RaisesMasterUnavailable
DisallowedStore
API Documentation for Launchpad, generated by pydoctor at 2022-06-16 00:00:12.