CSC/ECE 517 Fall 2010/ch2 2a aa

[Language extensions for ORM]

Introduction to Object Relational Mapping.

Object Relational Mapping is a technique of mapping the solution entities of an object oriented system, [1]objects to [2] relational database tables. This technique came into existence as an answer to the problem of lack of persistence of objects across session in [3]Object Oriented Programming Systems. For instance in a software solution to manage the order and inventory systems of a company, the objects that are part of the systems (orders, customers . . .) must be accessible even if the system was temporarily shut down for a while. [4]ORM helps in achieving this very essential requirement by bringing the database into the picture, more specifically bringing the RDBMS into the picture.

Why ORM, why not another solution?

The answer to this is quite an obvious one. ORM brings to the table something(s) that another solution hasn’t done so far. These “something(s)” that ORM contributes are listed below:

1. Alleviates the problem that hinders a transition from one database provider to another database vendor or even another database product.
2. Enables to perform most of the database operations ([5]mainly CRUD) without having to write any [6]SQL statements, thereby permitting a shift from one SQL dialect to another. This also allows the software solutions to focus more on the actual problem being solved rather that performing supplementary functions extensively.

Flavors of ORM solutions.

The term ORM is a very generic name for the class of solutions. Typically, ORM support in object oriented languages comes in two flavors; one that comes in separate packages which can be imported into our application, the other is the variety that comes incorporated into a language. When there is an option of choosing among the two flavors, the solution that come incorporated into the language is preferred. This choice may be quite an obvious one depending on the language that is being considered. Though the difference between the two might not be that apparent in the outset, the reason for this predilection towards the language incorporate solution over the other has mainly to do with design paradigm of the modern day software development of [7]“convention over configuration”. This paradigm emphasizes on the development by convention rather than development by configuration. The fact that the solution involving external packages and libraries involve a lot of configuration files which play the instructing role. In the language incorporated solution, such a problem doesn’t arise as the involvement of configuration files in the entire system itself is scanty. In the following sections we will take a look at two of the preferred language incorporated solutions.

ORM implementation in specific languages.

In this section, we will look at the language specific ORM examples illustrating the relation between creation of classes and tables, objects and rows, attributes and columns; and also examples for performing basic CRUD operations for the four OO languages.

Groovy, Grails and GROM:

Creating classes and tables:

Classes, when created using the create-domain-class, also create the table of the same name as the class (not the plural). For example,

grails create-domain-class Assignment

running the above command would create an empty class named Assignment and also create a table named Assignment in the database. Attributes to this class may be added in a fashion similar to the one followed in java. The attributes that are created in-turn gets automatically mapped to the columns in the table “Assignment”.

We may want to define the Assignment class as follows

class Assignment {
   String title
   Date dueDate
   String weightage_on_final_grade
}