Change Log

Version 1.1.0-Pre-Alpha

Rewrite of the PowerOrm

Release Date: Not Released


  • Registry

    This a registry of all the models the orm detected.

    • Manager

      This is in charge of managing all the command line related tasks for the orm, no need for users to create a migration controller to be able to work with the orm anymore

    • Doctrine Dbal

      Uses Doctrine Dbal to interact with the database.

    • Support

      • Migrations now supports all database supported by Doctrine Dbal
    • Migration Module:

      • Add Migrations commands

        • check
        • showmigration
        • migrate
        • makemigrations
        • robot
        • help
        • version
      • Migrations is able to support :

        • Alter/Remove/Add Operations relating to models.
    • Forms class

      • You can deal with forms in two ways :

        • Use the default form provided by the ORM

        • this is achieved by calling the $this->orm->get_form() which helps you build your form.

        • Define a form class in the forms folder.

          • create a forms folder at the same level as the libraries folder, if it does not exist.
          • inside it, Define a class the extends PForm class
          • just like model, override the fields() method and define you forms fields
          • and just like models, you the form fields from PForm e.g. PFORM::EmailField() .
      • the benefits of defining a form class is that it makes it very easy to do custom validations i.e. that those not handled by CI_form_validation class

    • From the orm orm object $this->orm you can be able to access the following :

      • registry = this->orm->get_registry()
      • orm version = this->orm->get_version()
      • Orm Form = this->orm->get_form()
        this builds a form based on the
        • orms core form class by default
        • use a custom form you have defined if you pass the form as an argument or
        • model to build a form based on a model that already exists.
    • Contributor, DeConstructable interface to provide a consistent way of deconstructing objects and contributing objects to other objects

Improvements and Fixes

  • Provides a consistent api for the models meta data, for easier access.
  • A consistent approach to how checks are carried out.
  • Migrations operations
  • Queryset to use the mode consistent model meta
  • Check system by redefining the check message levels


  • The whole migration module.

    • This module saw the addition of some important class:

      • AutoDetector - rewrite, keeps track of all changes within the models and produces the migration files..
      • Executor - responsible for running the migrations applying/unapplying.
      • Graph - Keeps track of how the migrations are related to each other i.e. which migration needs to run before which.
      • Migration - this was a rewrite, this is the base class for all migrations
      • Loader - this was a rewrite, loads migrations found in the migrations folder
      • Questioner - this was a rewrite
      • Recorder - this helps in keeping track of which migrations have been applied/unapplied by storing them in the database
      • State - this was rewrite to allow to use the new registry created
    • This drops using the CI_MIGRATION module and implements a differrent approach of doing migration this was prompted by need to reduce the number of migration files the previous version was producing

  • The whole console module

    • This removes the need for user to create a migration controller to be able to use the orm just copy the pmanger.php file located at ORM_PATH/pmanager.php to the same directory as index.php
    • This also provides a consistent api for adding more commands within the orm
  • The whole Form Module

    • This was done to enable defining forms as classes on a separate php file.

    • This rewrite resulted in the following classes:

      • Form - this is the overall class, it keeps track of a forms fields, form errors etc
      • Field - this keeps track of information relating to a form field like which errors it has, which label to use, the value of the field etc
      • Widget - this is responsible for rendering/ creating the expected html widget eg. input, textarea, password.
      • ValidationError - this thrown if a validation fails.
    • Whilst the new Form Module has its own validation technique, it heavily relies of the Ci_form_validation class. the new validation technique is meant to be used when doing validation that is not handle by Ci_form_validation class.

    You will mostly use it in the following form methods , i.e. if you have defined a form class :

    • the forms clean() method
    • the forms clean_{field_name}() method