A large portion of the information State manipulates lies inside of a PostgreSQL database. Anybody that's used a database knows that saving and pulling data is largely a repetitive process. In State, this task is much easier because much of time we're only pulling data from a single row of information, rarely using data from joins in our actual work. In order to make State easier to debug and operate I've created a simple Object Relational System to handle saving and loading data from the database. For each of object types we define a field mapping with all of the fields we're pulling into the object from our queries and their various properties. There are then a few methods which takes queries and these field mappings and create or save objects to the database.
A Peer is just a table in the database. If you've studied any Object Relational Systems you know'll recognize the term. Peer's manage objects of a specific type. It's the peer that stores the field mapping and other details that help us manage the objects in a specific table.
In a few areas we allow the ORS to generate the SQL we need, but only in simple situations where the SQL is very simple. Most of the time we have to write the SQL ourselves. Fortunately, the ORS helps us in the larger, more common case. Maybe someday we'll expand this, but right now things seem fine.
You may have noticed that there is a single library, libsos where all of the SQL lies. This is by design, to make any future changes easier to make maintaining the code easier. Any changes to the database will require changes to this library, and everything else should work just fine. Unless of course you change a field name or add new fields, then you'll have to use those fields and that will almost always happen outside of the sos library.