Roadmap
This page is currently a work-in-progress. The foundational work for DataMapper is happening in the veritas namespace, while DataMapper 2 will consist of a Mapper and glue code to pull in veritas, data_objects and other gems depending on the datastore.
This page will be updated as the DM core team discusses the priorities and outstanding tasks.
The high level design of DataMapper 2 should match the following:
The first pass has been done on the green section, and we have the Relation and Optimizer layers, as well as an RDBMS Adapter layer for PostgreSQL is ready for testing.
Virtus handles the Model and Introspection layers, although DM will be designed to map to any ruby object, not just those that are defined with Virtus. The primary benefit Virtus brings is that it provides a simple declarative API to define your models, and the mapping can be derived from this without manual mapping. It will be possible to map to a normal ruby object, except that the mapping will need to be manually specified.
The Mapper layer really is the core part of DataMapper 2. It’s what sits in between the Relation and the object. It should be relatively minimal and provide a Virtus-specific mapper that provides DataMapper 1 style mapping, as well as a base class that provides a way to manually map objects to relations. Ideally the Mapper should be relatively small; it should just perform one small function and delegate all the heavy lifting to other gems in the veritas or dm namespaces.
The Validation layer will be inferred from either the Relation or Model layer. Ideally each validation will be represented by a predicate inside the system. An instance will only be considered valid if the conjunction of all the predicates returns true.
The Constraint layer will be inferred from the validation layer. It will take each predicate and, if possible, define schema constraints or CHECK constraints that ensure the underlying data matches the constraints defined in the system. It will be responsible for ensuring foreign key constraints are declared too.
The Migration layer will take the constraints and be responsible for setting up the schema to match the relations that need to be stored in the datastore. It will be responsible for creating and updating the schema to match expectations. A DSL will be written to allow manual migrations to be defined for complex cases, while auto-migration and auto-upgrading support will be added using the same subsystem.
Currently, the priorities for each components is:
- Migration
- Validation
- Constraint
- Mapper
It’s assumed that after the first pass is performed on the above items, we’ll need to make a second pass to fill in the gaps we can’t see now both in between the components and missing pieces of “completed” layers. For example, it’s quite likely that once a rudimentary ORM is built on top using the Mapper we’ll find out that certain concepts in Veritas will need to be changed or added. It’s also quite possible we may have to do a few more passes on the optimizer in order to generate optimal SQL for certain use cases. Obviously work in these areas will be always be ongoing, but we want to ensure DM2 is at least as good as DM1 in the places where they overlap.