Dart Framework ORM M8

Another ORM? Why?

Immersing to the world of Flutter is a real and captivating adventure. Being a fairly new framework, there are plenty of opportunities to develop new libraries. As a result, I thought it was a good opportunity to set up an ORM to answer more questions. The goal is to have a framework that, besides relational mapping, provides the possibility to generate scaffolds for basic usage cases: user account, user data, data tracking (create, update, delete), soft delete. And that’s how begins the story of f-orm-m8.

Targeted audience

Dart/Flutter developers

Introduction

The framework adds definitions for a set of types that could be combined to expand ORM capabilities in the annotated code. The current version defines two main annotation types and some helpers associated with each definition:

• DataTable
• DataColumn

In order to ease the code emitting, four abstract classes are defined:

• DbOpenEntity: non constrained entity
• DbEntity: an entity with Id as primary key
• DbAccountEntity: a user account template with Id as primary key
• DbAccountRelatedEntity: user related data entities

DataTable

DataTable describes the required name for the table in conjunction with a bit mask for optional TableMetadata. Table metadata is specified with the parameter metadataLevel, and is a syntactic sugar to generate the proper fixture without explicitly adding the required fields.

TableMetadata

The TableMetadata describes the basic options for the table:

• softDeletable
• trackCreate
• trackUpdate

The options may be combined in various ways using | operator

DataColumn

The DataColumn describes how the fields will be transformed into entity attributes. The DataColumn constructor has three parameters:

• name
  - purpose: to specify the entity name
  - type: String
  - positional
  - mandatory
• metadataLevel
  - purpose: syntactic sugar to specify common use cases
  - type: int as combination of ColumnMetadata
  - named
  - optional
• compositeConstraints
  - purpose: a fine grain mode to specify composite constraints
  - type: List<CompositeConstraint>
  - named
  - optional

ColumnMetadata

Column metadata is specified with the parameter metadataLevel. Is a syntactic sugar to generate a quick fixture, offering basic options for the following use cases:

• ignore
• primaryKey
• unique
• notNull
• autoIncrement
• indexed

The options can be combined in various ways using | operator

The primaryKey, unique, indexed constraints can be generated in a targetted way using CompositeConstraint

CompositeConstraint

The composite constraint is able to specify the name and the type of the constraint. If the same name is used on multiple DataColumns, it will signal a composite constraint that will cover all the involved fields. The CompositeConstraint is instantiated with named, required parameters:

• name — the name of the constraint
• constraintType — the type of the constraint as enum with the following values:
  - unique,
  - primaryKey,
  - foreignKey,
  - indexed

A simple approach

DataColumn describes the required name for the column in conjunction with a bit mask for required column metadata.

A fine tuned approach

DataColumn describes the required name for the column in conjunction with a list of composite constraints. For example, if we need a composite, unique constraint defined on the combination of two fields, we define the composite with the same name:

Interfaces

DbOpenEntity

DbOpenEntity is, as it’s name suggests, a template for non restrictive models with composite primary keys. It can also be used for non integer primary key implementation.
It defines a single method getPrimaryKey

DbEntity

Can be used for a general purpose model template with integer primary key named id

DbAccountEntity

It implements DbEntity. Can be used for a model template in a generic user account with the following fields:

• userName
• email
• abbreviation
• isCurrent

DbAccountRelatedEntity implements DbEntity

It implements DbEntity. Can be used for a model template in a generic, account dependent, entity with the following fields:

• accountId

Usage convention

The package can be a start for other projects that aim to develop an ORM scaffolding infrastructure. It is up to developers how they implement the gems of this package. We recommend the annotations to be placed as in the following example:

All set? Let’s go

You’re looking for an implementation, aren’t you? Then, read how to quickly create a CRUD application with f-orm-m8.

References

matei-tm/f-orm-m8

If you have any questions or you would like to give me feedback, you’re invited to leave them below, on Gitter or Twitter.

May the f-orm-m8 be with you!