John Sullivan

Expose underlying database connections to the users

2

Let users have a back door to the database to do whatever they need to do. They can always open up another connection themselves; Having two database connections open from...

Implement `Repo.inplace.updateByKeyVal` and `Repo.inplace.updateByQuery` to do updates "in place", or on the database. - See #43 for discussion of `Repo.inplace` - Depends on #44, #46, and #47 - We may...

All fields will have to be realized. JSON removed. We probably want to support both this and the JSON format, e.g., as separate back ends. Your going to need to...

All fields will have to be realized. JSON removed. We probably want to support both this and the JSON format, e.g., as separate back ends. Your going to need to...

Implement `Repo.inplace.updateByKeyVal` and `Repo.inplace.updateByQuery` to do updates "in place", or on the database. - See #43 for discussion of `Repo.inplace` - Depends on #44. - The first has two arguments:...

This is prerequisite for any further `updateByKeyVal` or `updateByQuery` work. - I would recommend keeping it simple at first. - Follow `longevity.model.query.QueryFilter` as a rough model. - Basic structure is...

In place deletes

1

Add methods `Repo.deleteByKeyVal` and `Repo.deleteByQuery` to delete lots of rows "in place", i.e., without loading them from the database first. Perhaps we should put these in `Repo.inplace.deleteByKeyVal` and `Repo.inplace.deleteByQuery` so...

Right now, there are two major problems with the `longevity.test.TestDataGenerator` API. First, it's not functional. We should use a state monad approach to keep track of the current seed. Second,...

Right now it is an abstract class. Pull the public API of that class into a trait. Make the abstract class `private[longevity]`.

Right now these are implemented with runtime reflection. Move to compile time for faster application startup. See `longevity.model.annotations.packscanToList` for a general idea of how to do this.