BaseRepository
Base class for repositories -- the persistence abstraction for aggregates.
Repositories provide a collection-oriented interface (add, get, all)
to load and persist aggregates, hiding database details behind a clean domain API.
See Repositories guide for practical usage and Repositories concept for design rationale.
Bases: Element, OptionsMixin
This is the baseclass for concrete Repository implementations.
The three methods in this baseclass to add, get or all entities are sufficient in most cases
to handle application requirements. They have built-in support for handling child relationships and
honor Unit of Work constructs. While they can be overridden, it is generally suggested to call the
parent method first before writing custom code.
Repositories are strictly meant to be used in conjunction with Aggregate elements. It is always prudent to deal with persistence at the transaction boundary, which is at an Aggregate's level.
Source code in src/protean/core/repository.py
50 51 52 | |
add
add(item: Any) -> Any
This method helps persist or update aggregates or projections into the persistence store.
Returns the persisted item.
Protean adopts a collection-oriented design pattern to handle persistence. What this means is that the Repository interface does not hint in any way that there is an underlying persistence mechanism, avoiding any notion of saving or persisting data in the design layer. The task of syncing the data back into the persistence store is handled automatically.
To be specific, a Repository mimics a set collection. Whatever the implementation, the repository
will not allow instances of the same object to be added twice. Also, when retrieving objects from
a Repository and modifying them, you don't need to "re-save" them to the Repository.
If there is a Unit of Work in progress, then the changes are performed on the UoW's active session. They are committed whenever the entire UoW is committed. If there is no transaction in progress, changes are committed immediately to the persistence store. This mechanism is part of the DAO's design, and is automatically used wherever one tries to persist data.
Source code in src/protean/core/repository.py
98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 | |
get
get(identifier) -> Any
This is a utility method to fetch data from the persistence store by its key identifier. All child objects, including enclosed entities, are returned as part of this call.
Returns the fetched object.
All other data filtering capabilities can be implemented by using the underlying DAO's
BaseDAO.filter method.
Filter methods are typically implemented as domain-contextual queries, like find_adults(),
find_residents_of_area(zipcode), etc. It is also possible to make use of more complicated,
domain-friendly design patterns like the Specification pattern.
Source code in src/protean/core/repository.py
246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 | |