The ViewModel provides a high level db schema and interface to a database as well as an interface from the db to viewsCurrent version works with bottle framework and pymongohowever a previous version supported sqlalchemy and otherframeworks could be supported.
Project description
Uses
ViewModels are wrappers for the data ‘model’, that include details of the data useful in generating views. Generally the concept is to allow information and flexibly independent of the constraints of the underlying db.
Background
Instructions
‘Creating a ViewModel’_.
Uses
Interface to provide access to database
To access a collection in a simply Mongo through pymongo could not be much simpler. Similarly with other However this does not provide: - abstraction between code and database - types not covered in the BSON type set - joins - a record of schema in use
All these advantages are provided by using ViewModel. However there are times when none of these justifies an additional layer. The more complex the collection, the greater the amount of code, generally the greater the value of using ViewObject
Abstraction between code and database
Databases migrate. The Salt database started with direct SQL, then SQLAlchemy, then mongodb. Abstraction assists with migrations. The current Salt system uses Mongo and directly using the pymongo interface is can be perfect for simple access. A rewrite would be needed to change the db but the code is so small it is not a large barrier for small simple cases. But more complex cases are another matter!
Repository for description of data (schema)
NoSql collections (or tables) can effectively be irregular with different fields present potentially in every entry. While with SQL,just examining a row can give a reasonable view of that schema, it can be less clear from NoSql. Even with SQL, the schema recorded is restricted to what the database engine requires, and lacks richer descriptions of the data and rules not implemented by the database.
Increasing range of types available to applications
ViewModel provides mapping between the data in the database and the data seen by the application. Far more descriptive types and move complex types can be used by the application with the mapping between these types and the underlying storage format handle by the ViewModel
Background
History
The original Salt project development worked with SQL at a time when the SQLAlchemy project was still in early stages. So Salt developed its own layer to abstract to the database in 2007 around the same time as SQLAlchemy was developed. Both the salt ‘DataModel’ and SQLAlchemy libraries developed specific advantages, but as a popular open sourced project, SQLAlchemy became the more mature product. In 2015 the Salt project chose to replace the internal ‘DataModel’ library with the SQLAlchemy, due to wider use and greater development of the open source project, but then found several key features of ‘DataModel’ were missing from SQLAlchemy. The solution was a new library ‘ModelView’, which acted as an abstraction layer between SQLAlchemy and the application. The name ‘ModelView’ came from the fact that the main elements present in ‘DataModel’ that were missing from SQLAlchemy were data extended data schema information that were also useful in providing data description to views.
The next step brought the current ‘ViewModel’, by transforming that library to become an interface between pymongo and the application.
Data tables/collections and data views
The ViewModel package focuses on preparing data for views. How is the data in a table/collection to be viewed? For example, consider a ‘Products’ table or collection, where products may be viewed: - individually by product code, - as a list of products by product group, or by brand - as a list through a custom search
These become the views of the data from the database. It is never relevant to actually retrieve the entire table/collection for the products as if processing the entire table, each document will be processed in sequence. In contrast, there may be other table/collections with either a single or small fixed number of rows/collections the entire table/collection may constitute a view.
Further, product could have a join to a ‘pack sizes’ table/collection and for some views these are also part of the view.
The main concept is that each table has a set of relevant views of the table/collection for various uses. The viewmodel specifies not just the schema of the table/collection, but the actual views of the table/collection.
Instructions
Describing a table/collection
Create a class derived from a ModelView, add class attributes which are ‘ViewFields’ for each field in the table or collection. eg.:
from ViewModel import ViewModel, IdField, TxtField, IntField class ProductView(ModelView): viewName_ = "Products" id = IdField() label = TxtField('Label for Email', 8) stock_count = IntField()
Using ‘ViewField’ derived classes
xxx
Building HTML Forms
ObjDict can be initialised from lists, from JSON strings, from dictionaries, from parameter lists or from keyword parameter lists.
Updating from HTML forms
Custom classes allow for JSON data to result in instantiating objects other
than ObjDict from JSON data. These custom classes can be sub-classed from ObjDict
or built simply using the @to_JSON()
and/or @from_JSON()
decorators.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Hashes for ViewModel-0.1.0-py2.py3-none-any.whl
Algorithm | Hash digest | |
---|---|---|
SHA256 | 09c0dbad6c4820d3f5889ca89d99e9a4192d69f4146e3c3567441717b45e4f99 |
|
MD5 | bae92032e765f6343f789c1f3322d3e1 |
|
BLAKE2b-256 | 1ebc0aeb3eb69bf8f9e6c3b4a19b5c36f6a6bba4e515afe6c0c9b47ae5280f5d |