Server objects¶

Repository¶

eulfedora.server.Repository has the capability to automatically use connection configuration parameters pulled from Django settings, when available, but it can also be used without Django.

When you create an instance of Repository, if you do not specify connection parameters, it will attempt to initialize the repository connection based on Django settings, using the configuration names documented below.

If you are writing unit tests that use eulfedora, you may want to take advantage of eulfedora.testutil.FedoraTestSuiteRunner, which has logic to set up and switch configurations between a development fedora repository and a test repository.

Projects that use this module should include the following settings in their settings.py:

# Fedora Repository settings
FEDORA_ROOT = 'http://fedora.host.name:8080/fedora/'
FEDORA_USER = 'user'
FEDORA_PASSWORD = 'password'
FEDORA_PIDSPACE = 'changeme'
FEDORA_TEST_ROOT = 'http://fedora.host.name:8180/fedora/'
FEDORA_TEST_PIDSPACE = 'testme'
# optional retry setting (default is 3)
FEDORA_CONNECTION_RETRIES = None

If username and password are not specified, the Repository instance will be initialized without credentials and access Fedora as an anonymous user. If pidspace is not specified, the Repository will use the default pidspace for the configured Fedora instance.

Projects that need unit test setup and clean-up tasks (syncrepo and test object removal) to access Fedora with different credentials than the configured Fedora credentials should use the following settings:

FEDORA_TEST_USER = 'testuser'
FEDORA_TEST_PASSWORD = 'testpassword'

class eulfedora.server.Repository(root=None, username=None, password=None, request=None, retries=<object object>)¶

Pythonic interface to a single Fedora Commons repository instance.

Connect to a single Fedora Repository by passing in connection parameters or based on configuration in a Django settings file. If username and password are specified, they will override any fedora credentials configuredin Django settings.

If a request object is passed in and the user is logged in, this class will look for credentials in the session, as set by login_and_store_credentials_in_session() (see method documentation for more details and potential security risks).

Order of precedence for credentials:

If a request object is passed in and user credentials are available in the session, that will be used first.

Explicit username and password parameters will be used next.

If none of these options are available, fedora credentials will be set in django settings will be used.

If a retries value is specified, this will override the default set in Repository.retries which is used to configure the maximum number of requests retries for connection errors (see http://docs.python-requests.org/en/master/api/#requests.adapters.HTTPAdapter). Retries can also be specified via Django settings as FEDORA_CONNECTION_RETRIES; if an iniitalization parameter is specified, that will override the Django setting.

best_subtype_for_object(obj, content_models=None)¶

Given a DigitalObject, examine the object to select the most appropriate subclass to instantiate. This generic implementation examines the object’s content models and compares them against the defined subclasses of DigitalObject to pick the best match. Projects that have a more nuanced understanding of their particular objects should override this method in a Repository subclass. This method is intended primarily for use by infer_object_subtype().

Parameters:	obj – a `DigitalObject` to inspect content_models – optional list of content models, if they are known ahead of time (e.g., from a Solr search result), to avoid an additional Fedora look-up
Return type:	a subclass of `DigitalObject`

default_object_type¶

Default type to use for methods that return fedora objects - DigitalObject

alias of DigitalObject

find_objects(terms=None, type=None, chunksize=None, **kwargs)¶

Find objects in Fedora. Find query should be generated via keyword args, based on the fields in Fedora documentation. By default, the query uses a contains (~) search for all search terms. Calls ApiFacade.findObjects(). Results seem to return consistently in ascending PID order.

Example usage - search for all objects where the owner contains ‘jdoe’:

repository.find_objects(ownerId='jdoe')

Supports all search operators provided by Fedora findObjects query (exact, gt, gte, lt, lte, and contains). To specify the type of query for a particular search term, call find_objects like this:

repository.find_objects(ownerId__exact='lskywalker')
repository.find_objects(date__gt='20010302')

Parameters:	type – type of objects to return; defaults to `DigitalObject` chunksize – number of objects to return at a time
Return type:	generator for list of objects

get_next_pid(namespace=None, count=None)¶

Request next available pid or pids from Fedora, optionally in a specified namespace. Calls ApiFacade.getNextPID().

Deprecated since version 0.14: Mint pids for new objects with eulfedora.models.DigitalObject.get_default_pid() instead, or call ApiFacade.getNextPID() directly.

Parameters:	namespace – (optional) get the next pid in the specified pid namespace; otherwise, Fedora will return the next pid in the configured default namespace. count – (optional) get the specified number of pids; by default, returns 1 pid
Return type:	string or list of strings

get_object(pid=None, type=None, create=None)¶

Initialize a single object from Fedora, or create a new one, with the same Fedora configuration and credentials.

Parameters:	pid – pid of the object to request, or a function that can be called to get one. if not specified, `get_next_pid()` will be called if a pid is needed type – type of object to return; defaults to `DigitalObject`
Return type:	single object of the type specified
Create:	boolean: create a new object? (if not specified, defaults to False when pid is specified, and True when it is not)

get_objects_with_cmodel(cmodel_uri, type=None)¶

Find objects in Fedora with the specified content model.

Parameters:	cmodel_uri – content model URI (should be full URI in info:fedora/pid:### format) type – type of object to return (e.g., class:DigitalObject)
Return type:	list of objects

infer_object_subtype(api, pid=None, create=False, default_pidspace=None)¶

Construct a DigitalObject or appropriate subclass, inferring the appropriate subtype using best_subtype_for_object(). Note that this method signature has been selected to match the DigitalObject constructor so that this method might be passed directly to get_object() as a type:

>>> obj = repo.get_object(pid, type=repo.infer_object_subtype)

See also: TypeInferringRepository

ingest(text, log_message=None)¶

Ingest a new object into Fedora. Returns the pid of the new object on success. Calls ApiFacade.ingest().

Parameters:	text – full text content of the object to be ingested log_message – optional log message
Return type:	string

purge_object(pid, log_message=None)¶

Purge an object from Fedora. Calls ApiFacade.purgeObject().

Parameters:	pid – pid of the object to be purged log_message – optional log message
Return type:	boolean

retries = 3¶: default number of retries to request for API connections; see http://docs.python-requests.org/en/master/api/#requests.adapters.HTTPAdapter

risearch¶: instance of eulfedora.api.ResourceIndex, with the same root url and credentials

search_fields = [u'pid', u'label', u'state', u'ownerId', u'cDate', u'mDate', u'dcmDate', u'title', u'creator', u'subject', u'description', u'publisher', u'contributor', u'date', u'type', u'format', u'identifier', u'source', u'language', u'relation', u'coverage', u'rights']¶: fields that can be searched against in find_objects()

search_fields_aliases = {u'owner': u'ownerId', u'dc_modified': u'dcmDate', u'modified': u'mDate', u'created': u'cDate'}¶: human-readable aliases for oddly-named fedora search fields

class eulfedora.server.TypeInferringRepository(root=None, username=None, password=None, request=None, retries=<object object>)¶

A simple Repository subclass whose default object type for get_object() is infer_object_subtype(). Thus, each call to get_object() on a repository such as this will automatically use best_subtype_for_object() (or a subclass override) to infer the object’s proper type.

default_object_type(api, pid=None, create=False, default_pidspace=None)¶

Construct a DigitalObject or appropriate subclass, inferring the appropriate subtype using best_subtype_for_object(). Note that this method signature has been selected to match the DigitalObject constructor so that this method might be passed directly to get_object() as a type:

>>> obj = repo.get_object(pid, type=repo.infer_object_subtype)