Merge lp:~allenap/postgresfixture/it-begins into lp:~lazr-developers/postgresfixture/trunk
| Status: | Merged |
|---|---|
| Merged at revision: | 2 |
| Proposed branch: | lp:~allenap/postgresfixture/it-begins |
| Merge into: | lp:~lazr-developers/postgresfixture/trunk |
| Diff against target: |
1265 lines (+1192/-0) 14 files modified
.bzrignore (+10/-0) Makefile (+25/-0) README.txt (+43/-0) postgresfixture/__init__.py (+17/-0) postgresfixture/__main__.py (+17/-0) postgresfixture/cluster.py (+167/-0) postgresfixture/clusterfixture.py (+142/-0) postgresfixture/main.py (+185/-0) postgresfixture/testing/__init__.py (+25/-0) postgresfixture/tests/test_cluster.py (+186/-0) postgresfixture/tests/test_clusterfixture.py (+168/-0) postgresfixture/tests/test_main.py (+163/-0) requirements.txt (+3/-0) setup.py (+41/-0) |
| To merge this branch: | bzr merge lp:~allenap/postgresfixture/it-begins |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Richard Harding | code | 2012-05-14 | Approve on 2012-05-15 |
|
Review via email:
|
|||
Commit Message
It starts now.
Description of the Change
This is taken from an unlanded branch for the MAAS project, lp:~allenap/maas/database-run. I've then split it up and projectified it. I started using buildout until I just couldn't bear it any longer - it would not Just Work - so I switched to virtualenv+pip and have been much happier since. It's less powerful, but equally I have spent *much* less time toying with it.
| Robert Collins (lifeless) wrote : | # |
| Gavin Panella (allenap) wrote : | # |
> How is this better than van.pg which we already use? Looks like
> little/no difference. Did you try using van.pg?
I did try using van.pg and started writing wrappers around it to get
the behaviour I wanted, until it became apparent that van.pg made too
many assumptions that were not suitable.
Additionally:
- van.pg has 2 tests. This has 69.
- IMO, this models a cluster much better than van.pg. The model for a
pre-existing cluster and one that this code creates is the same;
van.pg has RunningCluster and Cluster, the former supporting a
subset of the operations of the latter.
- This has the concept of creating a cluster but preserving it instead
of destroying it. This makes subsequent runs quicker, and also helps
when using the cluster for local development.
- This has a command-line tool for working with the cluster. With this
it's easy to run a cluster, open a shell, stop, or destroy it.
- This has the concept of multiple users of the cluster. Only the last
user will stop or destroy the cluster. Again, this is useful for
local development, where a cluster is used both for the development
service and running tests.
- I believe that this is a better platform for future development; I
think it's higher quality.
- van.pg contains unavoidable code that seems very specific to someone
else's problem, in createdb() for example:
assert template is None or template.
assert template is None or int(template[7:]) <= self._db_counter, (template, self._db_counter)
Things van.pg has that this does not:
- Can be used as a test resource. However, so can postgresfixture via
FixtureResource.
- Integration with the transaction module when using the test resource
class, DatabaseManager (not sure why it's limited in this way). I
developed postgresfixture for Django in MAAS, which has its own way
of sorting out the database for tests, but it would be fairly simple
to add something like this if there was a need. Also,
- When not using the test resource, van.pg has ConnWrapper to try and
detect dirtied databases. It's a leaky abstraction though, and I
think there are better ways of doing this.
- Background creation of new databases; while one test runs a pristine
database is prepared. I wonder if this actually buys much.
| Richard Harding (rharding) wrote : | # |
Phew, so I've not used this or van.pg, but from a pure code review stand point. Thanks for the lesson that assertions will return items. I hadn't seen things like the .code on the assertRaises before.
- The dropdb test: does it provide no feedback that you're dropping a db that doesn't exist? Since the test asserts nothing, is it basically just that it runs?
- Just a suggestion to move the testtools requirement to a tests_require and try to wrap the test script into a test_suite entry in the setup.py so that the normal setup.py test can work and it'll fetch the extra dependency.
- As a new user, a little more in the readme, at least a hint as to the cmd line client name so I can hit up --help ootb would be useful. It links to the LP project page, but there's no additional usage/etc there I can see.
- There's a TODO, should this follow our XXX style in LP more? I'm not sure on how this works for outside projects.
| Gavin Panella (allenap) wrote : | # |
> Phew, so I've not used this or van.pg, but from a pure code review
> stand point. Thanks for the lesson that assertions will return
> items. I hadn't seen things like the .code on the assertRaises
> before.
>
> - The dropdb test: does it provide no feedback that you're dropping
> a db that doesn't exist? Since the test asserts nothing, is it
> basically just that it runs?
Yes. I've added a comment to make that clear.
>
> - Just a suggestion to move the testtools requirement to a
> tests_require and try to wrap the test script into a test_suite
> entry in the setup.py so that the normal setup.py test can work and
> it'll fetch the extra dependency.
Oh, that's perfect, great suggestion, thanks.
>
> - As a new user, a little more in the readme, at least a hint as to the cmd
> line client name so I can hit up --help ootb would be useful. It links to the
> LP project page, but there's no additional usage/etc there I can see.
Yes, I'll work on this before landing.
>
> - There's a TODO, should this follow our XXX style in LP more? I'm not sure on
> how this works for outside projects.
Oops, that's done, so I've removed it.
Thanks for the review!
- 25. By Gavin Panella on 2012-05-21
-
Comment about the dropdb test.
- 26. By Gavin Panella on 2012-05-21
-
Move test stuff into setup.py.
- 27. By Gavin Panella on 2012-05-21
-
Remove test script; use setup.py instead (via Makefile).
- 28. By Gavin Panella on 2012-05-21
-
Remove TODO; it's done.
- 29. By Gavin Panella on 2012-05-21
-
testtools is needed for running as well as tests.
- 30. By Gavin Panella on 2012-05-21
-
More docs.

How is this better than van.pg which we already use? Looks like
little/no difference. Did you try using van.pg?