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.
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,
: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
With one or two models, it is quite possible to tweak properties and models
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