GDL2: the GNUstep Database Library

Then, we need to create our EOModel programmatically. The EOModel is a correspondence between data stored in the database and an enterprise object. It defines entities for the tables in the databases and their attributes and relationships that correspond to table columns. Listing 5 shows tool/model.m, the tool used to create our model used by our application. For sake of simplicity, the model of our small inventory application defines only one entity.

For our small inventory application, we use EOF's built-in EOGenericRecord class for our EOEntity object, which describes our inventory table. We easily could define our own Item class and use it instead of EOGenericRecord in order to provide, for example, automatic validation of values the object can accept through mutation methods. In Listing 5, we also specify the attribute mappings used for our EOEntity. For example, the iid attribute is mapped to our IID database column and corresponds to the entity's primary key. In addition, it is used for locking during updates. When a value is read from the database, which has an int4 type, EOF automatically creates a NSNumber instance holding the corresponding value. The same operations are done for the three other attributes to be fetched into the application: name, quantity and order_date. Before leaving the tool's main() function, we set the name of the adaptor to be used, Postgres95 in this example, and the database name. We then write the EOModel on disk.

To compile the tool, a small GNUmakefile must be created. Listing 6 is the GNUmakefile.

Before running the test application, we first must run, only once, the tool that creates our EOModel. To do so, proceed with the following commands:

# cd tool
# make
# opentool shared_obj/model

This creates the Inventory.eomodeld directory, which holds all the information (the two plists) with regard to our EOModel. To compile and run our test application, proceed with the following commands:

# cd ..
# make
# openapp Inventory.app

Once the application has finished launching, -applicationDidFinishLaunching: is automatically invoked. In this method, we added the code to initialise EOF from our model. We also run the PostgreSQL's adaptor login panel (shown in Figure 3) in order to specify the user name/password and database name we want to use. In the future, GDL2 will offer the possibility to create databases directly from the login panel. For now, from this panel, enter inventory in the Username: and Database: fields, the password you assigned to the inventory user when creating it in the Password: field. Then, click on the Ok button.

Figure 3. Logging in to the inventory application

From the Inventory application, clicking on the Update button invokes the -update: method. In this method, we fetch all items from our database. Each item, which corresponds to a database row, is an instance of the EOGenericRecord class. Once EOF is done fetching the items, we reload our table view. Doing so automatically invokes -numberOfRowsInTableView: and -tableView:objectValueForTableColumn:row:. The former returns the number of fetched enterprise objects while the latter first gets the EOGenericRecord instance corresponding to the displayed row and returns the appropriate value for the table column using Key-Value-Coding (KVC).

Clicking on the Insert button calls the -insert: method in which we create an EOGenericRecord instance, set initial values (using KVC) and then register it to be inserted in our EOObjectStore. EOF automatically generates a unique ID, using the database sequence, and creates a database row. Finally, clicking on the Delete button invokes the -delete: method. In this method, we remove our enterprise object from the EOOjectStore, which removes the database row.

Live editing on the table view also is supported in our test application. The implementation of the -tableView:setObjectValue:forTableColumn:row: method offers us support for this functionality. In this method, we first obtain the enterprise object corresponding to our edited row. We then set the modified value to the right key, which is mapped to the right table column, based on our EOModel object.