Working with Legacy Schemas

DataMapper has quite a few features and plugins which are useful for working with legacy schemas. We're going to introduce the feature available in the core first, before moving on to plugins. Note that whilst the title is "Working with Legacy Schemas", really this applies to any situation where there is no control over the 'table' in the data-store. These features could just as easily be used to modify the fields returned by a RESTful webservice adapter, for example.

Small Tweaks

If the number of modifications are small—just one table or a few properties—it is probably easiest to modify the properties and table names directly. This can be accomplished using the :field option for properties, :child_key (or :target) for relationships, and manipulation of storage_names[] for models. In all the following examples, the use of the :legacy repository name assumes that it is some secondary repository that should behave in the special manner. If it is the main database the application will be interacting with, :default makes a much more sensible choice. Note that for the below snippet to work, you need to have have the :legacy repository set up properly.

 1 class Post
 2   include DataMapper::Resource
 3 
 4   # set the storage name for the :legacy repository
 5   storage_names[:legacy] = 'tblPost'
 6 
 7   # use the datastore's 'pid' field for the id property.
 8   property :id, Serial, :field => 'pid'
 9 
10   # use a property called 'uid' as the child key (the foreign key)
11   belongs_to :user, :child_key => [ :uid ]
12 end

Changing Behaviour

With one or two models, it is quite possible to tweak properties and models using :field and storage_names. When there is a whole repository to rename, naming conventions are an alternative. These apply to all the tables in the repository. Naming conventions should be applied before the model is used as the table name gets frozen when it is first used. DataMapper comes with a number of naming conventions and custom ones can be defined:

 1 # the DataMapper model
 2 class Example::PostModel
 3 end
 4 
 5 # this is the default
 6 DataMapper.repository(:legacy).adapter.resource_naming_convention =
 7   DataMapper::NamingConventions::Resource::UnderscoredAndPluralized
 8 Example::PostModel.storage_name(:legacy)
 9 # => example_post_models
10 
11 # underscored
12 DataMapper.repository(:legacy).adapter.resource_naming_convention =
13   DataMapper::NamingConventions::Resource::Underscored
14 Example::PostModel.storage_name(:legacy)
15 # => example/post_models
16 
17 # without the module name
18 DataMapper.repository(:legacy).adapter.resource_naming_convention =
19   DataMapper::NamingConventions::Resource::UnderscoredAndPluralizedWithoutModule
20 Example::PostModel.storage_name(:legacy)
21 # => post_models
22 
23 # custom conventions can be defined using procs, or any module which
24 # responds to #call. They are passed the name of the model, as a string.
25 module ResourceNamingConvention
26   def self.call(model_name)
27     'tbl' + DataMapper::Inflector.classify(model_name)
28   end
29 end
30 
31 DataMapper.repository(:legacy).adapter.resource_naming_convention =
32   ResourceNamingConvention
33 Example::PostModel.storage_name(:legacy)
34 # => 'tblExample::PostModel'

For field names, use the field_naming_convention menthod. Field naming conventions work in a similar manner, except the #call function is passed the property name.