(TODO: Sadly, the sub-links in this example seem to be gone. Figure out if that content is still around somewhere and restore it. It's probably badly out of date too)
To define an application, we need to have three things
The domain model
The database tables
A definition of the mapping between them
So let's start with a very simple application. We'll organize a sports league, but we'll start just by keeping a list of the players and what team they're on. So our domain model will be just
Player
firstName
lastName
address
teamName
For a database table, we'll define a table that corresponds. We'll use the convention of using upper case for table and field names, to make it obvious when we mean classes or instance variables rather than tables and fields.
PLAYER
FIRST_NAME
LAST_NAME
ADDRESS
TEAM_NAME
Defining the domain model is easy, but for defining the tables, we can either do that in the database itself, or we can define the table structure in Glorp, and have it create the tables for us. In more serious applications, the tables probably already exist, or if we want to create them, we need to ask the DBA. If you're comfortable creating the table using database tools, go ahead and do that. Otherwise, see Creating Tables (Basic).
Now we need to define the information that Glorp needs to know what to do for our application.
For all of these, there's a lot of information we can just leave out and let Glorp figure out the details when it's obvious, and only fill them in if there's something complicated going on.
For example, in general, we have to tell a descriptor system which classes we want to map. But we can usually leave that out just by defining the methods for those classes. In some cases, we can even leave out the methods, and rely on Glorp picking up classes which are in the same namespace (check this, it might actually look at the package?) as the DescriptorSystem subclass. And similarly we have to tell it which tables we're interested in, but it will automatically see the tables we've defined in Smalltalk.