Hi,

I'm just getting started with go-ap, building a new type of single-user
instance, which uses sqlite as the db.

I'm wondering if you could add a method to the repository to get the
underlying database connection.

This would make it easier to integrate with an application that needs to
store more data in the database.

Something like this would work:

```
func (r *repo) Connection() (*sql.DB, error) {
     if err := r.Open(); err != nil {
        return nil, err
     }
     return r.conn, nil
}
```

I think this would be a good usability improvement. The call8ng code
would still need to call defer r.Close afterwards.

Thanks for your great work!

On 24-09-14 21:50:12, Dan Jones wrote:
> Hi,
> 
> I'm just getting started with go-ap, building a new type of single-user
> instance, which uses sqlite as the db.

Hello Dan I'm glad to hear that. :)

> I'm wondering if you could add a method to the repository to get the
> underlying database connection.
> 
> This would make it easier to integrate with an application that needs to
> store more data in the database.

Frankly I think that reusing the same sqlite database for multiple
facets of your application is the wrong way to think about the problem,
because sqlite, unlike most database engines, is very cheap to use.
There's no need to be frugal with connections, and there's no overhead
in having multiple databases in use at one time.

I am actually trying to write a new sqlite storage abstraction that will
make use of this idea, by sharding the data for each actor - ie, each
actor will have their own individual sqlite db. (The fact that an sqlite
db can have a unique writer at a time is another pain point that gets
solved by having multiple dbs)

So my first advice would be to reconsider your approach and try making
use of multiple databases.

> Something like this would work:
> func (r *repo) Connection() (*sql.DB, error)

Sorry to say but this is not something I'm willing to add to the code,
mainly because I don't want the storage types to be leaky abstractions
over whatever underlying technology they use.

I would entertain however a patch or PR that moves the functionality
from your method to a function similar to the following:

    // the *repo type implements this interface already :)
    func RawConnection(r interface { Open() error }) (*sql.DB, error)

This function would use a type assertion for the OpenCloser argument to
the *repo type and return its connection property, otherwise would error
out.

So this way the storage-sqlite package would give you a way to access
the underlying sql.DB but the type itself would not leak its
implementation details through the methods it exposes.

Let me know which solution you like more.

Cheers,
/Marius