| 00:00.20 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 03:12.25 | *** join/#storm _mup__ (~mup@li37-90.members.linode.com) |
| 04:45.03 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 05:40.09 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 05:49.54 | *** join/#storm lianglei (~lianglei@14.107.122.56) |
| 05:50.21 | *** part/#storm lianglei (~lianglei@14.107.122.56) |
| 06:48.48 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 09:22.34 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 09:26.28 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 09:40.32 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 10:23.02 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 11:02.30 | *** join/#storm niemeyer (~niemeyer@201-11-202-169.pltce701.dsl.brasiltelecom.net.br) |
| 11:02.30 | *** mode/#storm [+o niemeyer] by ChanServ |
| 11:44.51 | *** join/#storm esteve (~quassel@91.126.88.6) |
| 15:59.13 | *** join/#storm fcorrea (~fcorrea@187.3.129.150) |
| 22:16.34 | magmatt | Do I use schema.schema.Schema or schema.patch.PatchApplier directly? |
| 22:19.51 | magmatt | oh, I think I see. The full, end-result schema is to be provided to Schema() as creates, etc... while the patches are a way to get to the end-result. |
| 22:20.23 | magmatt | I was thinking of instead listing all patches, which, taken together, gets you to the desired state (which isn't explicitly written) |
| 23:10.09 | jkakar | magmatt: Yeah, so what we have is maybe suboptimal in one sense and great in another... |
| 23:10.41 | jkakar | magmatt: It's suboptimal in that it created duplication. The idea is that the Schema represents the current state-of-the-universe of your schema, such that you can always build the correct thing from scratch. |
| 23:11.02 | magmatt | jkakar: which is nice in some cases |
| 23:11.08 | jkakar | magmatt: That's useful because it can be used (primarily) in a test suite to bootstrap a fresh database. |
| 23:11.27 | jkakar | magmatt: But then you have patches which must be applied in production to get your deployed setups to the same thing. |
| 23:11.49 | *** join/#storm bigjools (~quassel@60-241-216-21.static.tpgi.com.au) |
| 23:11.49 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 23:12.09 | jkakar | magmatt: That said, you can create the Schema once and then always use patches, at the expense of some slowdown in your test suite, but you'll probably run into some mismatch issues (for example, the DELETE statements need to always be kept up-to-date for them to work well in your test suite). |
| 23:12.26 | jkakar | magmatt: So far I've only seen a couple of minor issues in several years of using this model, but the potential is there for skew. |
| 23:13.55 | magmatt | jkakar: okay, thanks, as always |
| 23:14.04 | jkakar | magmatt: No worries. |
| 23:14.15 | magmatt | how's fluidinfo going? |
| 23:14.16 | jkakar | magmatt: One day I'll finish my Storm documentation branch and these things will be more obvious. |
| 23:14.30 | jkakar | magmatt: It's going pretty well, thanks. Things are moving in the right direction. :) |
| 23:17.47 | magmatt | one day, I'll play with fluidinfo again :) |
| 23:17.50 | magmatt | well, good luck |