Skip to content

Commit 108a01f

Browse files
committed
docs: update DEVELOPER_DOCUMENTATION
1 parent c7a7084 commit 108a01f

File tree

1 file changed

+10
-6
lines changed

1 file changed

+10
-6
lines changed

DEVELOPER_DOCUMENTATION.md

+10-6
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
* API - [lib/pact_broker/api](lib/pact_broker/api)
88
* Routes - [lib/pact_broker/api.rb](lib/pact_broker/api.rb)
99
* HTTP Resources - [lib/pact_broker/api/resources](lib/pact_broker/api/resources) These handle the HTTP requests.
10-
* Decorators - [lib/pact_broker/api/decorators](lib/pact_broker/api/decorators) These render the response bodies.
10+
* Decorators - [lib/pact_broker/api/decorators](lib/pact_broker/api/decorators) These parse the request bodies and render the response bodies.
1111
* Contracts - [lib/pact_broker/api/contracts](lib/pact_broker/api/contracts) These validate incoming API requests.
1212
* UI - [lib/pact_broker/ui](lib/pact_broker/ui)
1313
* Routes - [lib/pact_broker/ui/app.rb](lib/pact_broker/ui/app.rb)
@@ -35,10 +35,13 @@ Domain classes are found in `lib/pact_broker/domain`. Many of these classes are
3535

3636
* `pacticipant` - an application that participates in a pact. A very bad pun which I deeply regret.
3737
* `pact` - this term is confusing and overloaded. It generally means a `pact publication` in the code.
38-
* `pact publication` - the resource that gets created when a PUT request is sent to the Pact Broker to /pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION.
38+
* `pact publication` - the resource that gets created when a PUT request is sent to the Pact Broker to `/pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION`.
3939
* `pact version` - the JSON contents of the pact publication. One pact version may belong to many pact publications. That is, if a pact publication with exactly the same contents is published twice, then a new
40-
pact publication resource will be created, but it will reuse the existing pact version.
40+
pact publication resource will be created with an incremented revision number, but it will reuse the existing pact version.
41+
* `pacticipant version` - a resource that represents a version of the application
42+
* `integration` - the relationship between a consumer and a provider
4143
* `pseudo branch` - A time ordered list of pacts that are related to a particular tag. The most recent pact for each pseudo branch is a "head" pact.
44+
* `matrix` - the table that shows the cartesian join of pact versions/verifications, and hence shows which consumer versions and provider versions have been tested together.
4245

4346
### Tables
4447
* `pact_versions` - the JSON content of each UNIQUE pact document is stored in this table. The same content is likely to be published over and over again by the CI builds, so deduplicating the content saves us a lot of disk space. Once created, a row is never modified. Uniqueness is just done on string equality - no special pact logic. This means that pacts with randomly generated values or orders (most of pact-jvm pacts!) will get a new version record every time they publish.
@@ -80,11 +83,11 @@ pact publication resource will be created, but it will reuse the existing pact v
8083
* `consumer version number` and `consumer version order`
8184
* `revision_number`
8285

83-
* `latest_pact_publications_by_consumer_versions` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for each provider/consumer/version. It maps to what a user would consider the "pact" resource ie. `/pacts/provider/Provider/consumer/Consumer/version/1.2.3`. Previous revisions are not currently exposed via the API.
86+
* `latest_pact_publications_by_consumer_versions` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for each provider/consumer/version. It maps to what a user would consider the "pact" resource ie. `/pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION`. Previous revisions are not currently exposed via the API.
8487

8588
The `AllPactPublications` Sequel model in the code is what is used when querying data for displaying in a response, rather than the normalised separate PactPublication and PactVersion models.
8689

87-
* `latest_pact_publications` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for the latest consumer version for each consumer/provider pair. It is what a user would consider the "latest pact", and maps to the resource at `/pacts/provider/Provider/consumer/Consumer/latest`
90+
* `latest_pact_publications` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for the latest consumer version for each consumer/provider pair. It is what a user would consider the "latest pact", and maps to the resource at `/pacts/provider/PROVIDER/consumer/CONSUMER/latest`
8891

8992
* `latest_tagged_pact_publications` - This view has the same columns as `all_pact_publications`, plus a `tag_name` column. It is used to return the pact for the latest tagged version of a consumer.
9093

@@ -116,8 +119,9 @@ pact publication resource will be created, but it will reuse the existing pact v
116119
117120
```
118121

122+
### Database modeling approach
119123

120-
124+
In the beginning, I made a lot of Sequel models based on views that pulled in the different tables of data together (eg denormalising consumer, provider, pact publication and pact version in to `all_pact_publications`). This made the Ruby code quite simple, but it was not very performant. As time has progressed, I have moved more and more of the "data joining" code into the Ruby to optimise the queries. That's why there are a lot of "aggregated data" views that are not being used by the code any more.
121125

122126
### Useful to know stuff
123127

0 commit comments

Comments
 (0)