Roadmap

Purpose of this page

DataMapper development is community driven, and priority is based on contributor need. This page lists the things the contributors are interested in seeing in DataMapper prior to 1.0

0.10.0

The goal of the 0.10.0 release is to spec the intended behavior of the 0.9 series. The public API changes should be minimal, and when there are changes the old interfaces should continue to work but display warnings.

The semipublic API has some changes, especially for Adapters. The changes will likely break existing adapters, but the benefit will be that compliant adapters will support OR, AND, NOT queries both flat and nested.

0.10.x series

The 0.10.0 series will likely be the last before the 1.0 release (no release date).

Here are some of the planned features:

• Pluggable identity map. Why not have IM that can use any store Moneta supports, like Memcached, Tokyo Tyrant or Redis?

• Simplify Adapter API
  • create a layer in front of adapters that do not natively support inner joins, that will split up the Query, perform each part separately and
    then join the results in-memory.

• Update auto-migrate for DO adapters to use most efficient column type for a given Property
  • Make it easy for types to specify on a per-adapter basis which column types should be used for a given property
    • When a property is added to a model in a DO backed repository, mixin a column_schema method that returns a String to be used for the column in the CREATE TABLE statement. This will work because property objects are bound to the repository they are created under.

• Update auto-upgrade for DO adapters to introspect the DB and non-destructive things like lengthen columns, or changing NOT NULL to NULL allowed. (using a dm-reflections gem)
• Could even inspect the values in the table and perform the change provided nothing will be truncated or altered.
• Non-Unique Indexes can be added/removed at will
• Unique indexes can be added provided the actual data really is unique

• Move DO adapters into dm-more as dm-mysql-adapter, dm-postgres-adapter and dm-sqlite3-adapter

• Move lib/dm-core/migrations.rb into dm-migrations

• Move lib/dm-core/transaction.rb into dm-transaction

• Move Paranoid types out into dm-types

• Unify Property and Type
  • Create one DM::Property subclass for each primitive: Gist
  • Move type specific code from DM::Property into subclasses
  • Move type specific options to subclasses
    • Throw exceptions when wrong option used, like :size in a String object.
  • Update dm-types to inherit from DM::Property

• Update dm-validations to mix-in behavior into the DM::Property subclass
  • Make as much as possible introspectable, even error message templates.
  • Mix-in a method into the Property that makes it easy to check a Resource and see if it’s ivar(s) are valid

• Update dm-validations to add validations when has 1..3 used to ensure the minimal/maximal number of children is present.
  • Should also work for has 1, has 1..n, etc

• Allow :order => nil to be specified in Model#all and Collection#all and would result in the storage engine not ordering the results at all.

• Added EmbeddedValue with the same API as DM::Model, eg:

  class Address
    include DataMapper::EmbeddedValue
  
    property :street,      String
    property :location,    String
    property :subdivision, String
    property :postal_code, String
    property :country,     String
  end
  
  class User
    include DataMapper::Resource
  
    property :id,      Serial
    property :name,    String
    property :address, Address
  end

• There is a need to have more than one type of Query at least for purposes of full text search, which dm-is-searchable adapters may extend instead of writing everything from scratch

• Since dm-validations can be used with pure Ruby classes, why not try to implement a DSL for embedded values that may sit on top of custom types: YAML and JSON