/genesisng

An example repository on how to use SQL Alchemy with Zato.

Primary LanguagePythonGNU General Public License v3.0GPL-3.0

Genesis Next-Generation

A prototype application to demonstrate the many features of Zato when using SQLAlchemy to access a database, but also used to test a number of libraries, both for Python and for PostgreSQL. The concept is roughly based on a previous test project called [genesis][https://bitbucket.org/jsabater/genesis].

It features a services back-end for a boutique hotel management system. Many of its features are not supposed to make strict sense in the real world, but rather show how a functionality is meant to be used or just some of its possibilities.

It started being a Python 2.7 project but now it only supports Python 3.6 or greater.

Current features

The following schema classes have been defined using SQLAlchemy's declarative model:

  • login: represents a user that can log into the system.
  • guest: represents a guest that makes a reservation and features an enumerate type Gender, a hybrid property and a number of GIN indexes.
  • room: represents a room in the system and features the use of the Hashids library to generate a unique, public code for each room, two hybrid properties and a check constraint.
  • rate: represents a pricing rate in the system and features a hybrid property and an exclude constraint using date ranges.
  • booking: represents a booking in the system and features two enumerate types, the use of the Nano ID library to generate a random, short, public locator, the use of the random library to create a Personal Identification Number (PIN), a check constraint, a hybrid property and the use of the UUID and JSON types.
  • extra: represents an additional service of a booking in the system, which are retrieved from this table but then stored as a JSON document inside the extras column of the booking model class.

The application also has a number of services, spread among the following modules. The following list summarizes the services in each module:

  • login: get, validate, create, delete, update and list.
  • guest: get, create, delete, update , upsert, list, booking and restore.
  • room: get, create, delete, restore, update and list.
  • rate: get, create, delete, update and list.
  • booking: get, locate, create, cancel, delete, update, changepin, validate, list and restore.
  • availability: search, extras and confirm.

Logins and rates records are deleted. The rest are marked as deleted by setting the timestamp of deletion on the deleted column.

There are two types of services:

  • Tier-1. Services that work with one model class only in order to create, delete, update, get or list records of such entity in the database.
  • Tier-2. Services that use tier-1 services to offer more complex functionality and may pass on a session parameter to keep all SQL sentences inside a single transaction.

All services make use of the Cache API, using hand-crafted cache keys. Handling of cache entries in cache collections is done in every service following the business logic required by the application.

Some listings include a number of common features in REST API, such as:

  • Pagination, using a page number and a page size.
  • Sorting, using a direction and a criteria.
  • Filtering, which allows multiple filters and operators.
  • Fields projection, which lets the developer choose which fields from the model class are to be returned.
  • Search, which are case insensitive and take just one term.

Documentation

Project documentation, extracted from the code, can be generated by running make html inside the docs subdirectory. It has been created using Sphinx, which has been set as a project requirement.

Part of the information provided on this file is also available there.