The main goal of the first pass of ORM (haven) is to implement our generic object storage interface (Resources identified by Uris) using a relational database. To that goal, haven becomes more of an implementation detail that will be transparent to the application that is storing the objects.

The primary interface to the database will be via Resources and will be a basic CRUD interface. Prior to our discussion this was our CRUD interface:

Uri:
   Resource resolve()

Resource:
   new make(Uri uri, Obj obj)
   Resource create()
   Void save()
   Void delete()

This was problematic for relational databases and possibly other object stores where the uri is often either assigned by the store when the object is added or derived from the object's configuration. To handle this case we have added another method to add a child resource to an existing resource:

Resource:
   Resource add(Obj)

Also during this discussion we decided that what is currently called Connection will be renamed to Db. Db will become an abstract class with database specific implementations to handle differences in data types and feature implementations (like auto increment). Actual database connections will be limited to one connection per thread per database. That limitation makes sense and will likely mean that the connection does not need to be exposed directly in the API. Instead, the connection will be set as a thread local variable that is only accessed by the Db instance.

One remaining detail is to determine what API hooks will be provided for cleaning up connections.

userRc := `/users/john'.resolve
userRc.obj->lastName = "Jingleheimerschmidt"
userRc.save

What is the connection lifecycle for these statements? Ideally a single connection would be opened for the resolve and closed after the save. Or if multiple modifications are made a single connection would be used for all of them. In this case, there is no direct reference to the database so there's nothing to call close() on. We need to decide how that will work.