Repository: prest/prest
Pull request #762 (2023-01-15 12:20:35)

Toml optional
fix https://github.com/prest/prest/issues/257 , https://github.com/prest/prest/issues/561

pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `297` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +163 -134
Percentile : 69.7%

Total files changed: 5

Change summary by file extension:
.go : +118 -97
.md : +45 -37
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


codecov[bot]: # [Codecov](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest) Report
Base: **74.38**% // Head: **74.56**% // Increases project coverage by **`+0.17%`** :tada:
> Coverage data is based on head [(`411cad4`)](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest) compared to base [(`a62cc79`)](https://codecov.io/gh/prest/prest/commit/a62cc79d7f7c9d7c731a3011d60953cd37ebd1c1?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest).
> Patch coverage: 72.04% of modified lines in pull request are covered.

<details><summary>Additional details and impacted files</summary>


```diff
@@            Coverage Diff             @@
##             main     #762      +/-   ##
==========================================
+ Coverage   74.38%   74.56%   +0.17%     
==========================================
  Files          26       26              
  Lines        3252     3298      +46     
==========================================
+ Hits         2419     2459      +40     
- Misses        701      710       +9     
+ Partials      132      129       -3     
```


| [Impacted Files](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest) | Coverage Δ | |
|---|---|---|
| [adapters/postgres/internal/connection/conn.go](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest#diff-YWRhcHRlcnMvcG9zdGdyZXMvaW50ZXJuYWwvY29ubmVjdGlvbi9jb25uLmdv) | `74.11% <14.28%> (ø)` | |
| [config/config.go](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest#diff-Y29uZmlnL2NvbmZpZy5nbw==) | `85.95% <75.60%> (+1.06%)` | :arrow_up: |
| [adapters/postgres/postgres.go](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest#diff-YWRhcHRlcnMvcG9zdGdyZXMvcG9zdGdyZXMuZ28=) | `72.20% <100.00%> (-0.09%)` | :arrow_down: |

Help us with your feedback. Take ten seconds to tell us [how you rate us](https://about.codecov.io/nps?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest). Have a feature suggestion? [Share it here.](https://app.codecov.io/gh/feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest)

</details>

[:umbrella: View full report at Codecov](https://codecov.io/gh/prest/prest/pull/762?src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest).   
:loudspeaker: Do you have feedback about the report comment? [Let us know in this issue](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=prest).

pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `313` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +179 -134
Percentile : 71.3%

Total files changed: 5

Change summary by file extension:
.go : +134 -97
.md : +45 -37
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `342` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +187 -155
Percentile : 74.2%

Total files changed: 8

Change summary by file extension:
.go : +134 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `342` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +187 -155
Percentile : 74.2%

Total files changed: 8

Change summary by file extension:
.go : +134 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `349` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +188 -161
Percentile : 74.9%

Total files changed: 9

Change summary by file extension:
.yml : +7 -16
.go : +134 -97
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `348` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +190 -158
Percentile : 74.8%

Total files changed: 9

Change summary by file extension:
.yml : +9 -13
.go : +134 -97
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `354` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +193 -161
Percentile : 75.4%

Total files changed: 9

Change summary by file extension:
.yml : +12 -16
.go : +134 -97
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `342` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +187 -155
Percentile : 74.2%

Total files changed: 8

Change summary by file extension:
.go : +134 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `342` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +187 -155
Percentile : 74.2%

Total files changed: 8

Change summary by file extension:
.go : +134 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `343` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +188 -155
Percentile : 74.3%

Total files changed: 8

Change summary by file extension:
.go : +135 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.


pull-request-quantifier[bot]: ### ![](https://img.shields.io/static/v1?label=Quantified&message=Large&color=red)

This PR has `343` quantified lines of changes. In general, a change size of upto `200` lines is ideal for the best PR experience!

------

<details >
    <summary display="inline"> <strong>Quantification details</strong></summary>
    <p />

```
Label      : Large
Size       : +188 -155
Percentile : 74.3%

Total files changed: 8

Change summary by file extension:
.go : +135 -97
.yml : +6 -10
.md : +45 -37
.toml : +0 -8
Dockerfile : +2 -3
```
> Change counts above are quantified counts, based on the [PullRequestQuantifier customizations](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md).
    
</details>


<details>
    <summary display="inline"> <strong>Why proper sizing of changes matters</strong> </summary>
    <p/>
    <p/>

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

- Fast and predictable releases to production:
  - Optimal size changes are more likely to be reviewed faster with fewer
iterations.
  - Similarity in low PR complexity drives similar review times.
- Review quality is likely higher as complexity is lower:
  - Bugs are more likely to be detected.
  - Code inconsistencies are more likely to be detected.
- Knowledge sharing is improved within the participants:
  - Small portions can be assimilated better.
- Better engineering practices are exercised:
  - Solving big problems by dividing them in well contained, smaller problems.
  - Exercising separation of concerns within the code changes.

#### What can I do to optimize my changes

- Use the PullRequestQuantifier to quantify your PR accurately
  - Create a context profile for your repo using the [context generator](https://github.com/microsoft/PullRequestQuantifier/releases)
  - Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the `Excluded` section from your `prquantifier.yaml` context profile. 
  - Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your `prquantifier.yaml` context profile.
  - Only use the labels that matter to you, [see context specification](./docs/prquantifier-yaml.md) to customize your `prquantifier.yaml` context profile.
- Change your engineering behaviors
  - For PRs that fall outside of the desired spectrum, review the details and check if:
    - Your PR could be split in smaller, self-contained PRs instead
    - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

#### How to interpret the change counts in git diff output

- One line was added: `+1 -0`
- One line was deleted: `+0 -1`
- One line was modified: `+1 -1` (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
- Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

</details>

<p />

------

Was this comment helpful? <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNVcCJ9&amp;anonymous=True" target="_blank" title="Thumbs up"><strong>:thumbsup:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJOZXV0cmFsIn0=&amp;anonymous=True" target="_blank" title="Neutral"><strong>&nbsp;:ok_hand:</strong></a> <a href="https://pullrequestquantifierfeedback.azurewebsites.net/feedback?payload=eyJBdXRob3JOYW1lIjoiYXJ4ZHNpbHZhIiwiUmVwb3NpdG9yeUxpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QiLCJQdWxsUmVxdWVzdExpbmsiOiJodHRwczovL2dpdGh1Yi5jb20vcHJlc3QvcHJlc3QvcHVsbC83NjIiLCJFdmVudFR5cGUiOiJUaHVtYnNEb3duIn0=&amp;anonymous=True" target="_blank" title="Thumbs down"><strong>&nbsp;:thumbsdown:</strong></a> (<a href="MAILTO:prquantifier@microsoft.com" title="Mail to prquantifier@microsoft.com">Email</a>)
[Customize PullRequestQuantifier](https://github.com/microsoft/PullRequestQuantifier/blob/main/docs/prquantifier-yaml.md) for this repository.



Patch:
diff --git a/Dockerfile b/Dockerfile
index a8053ce..1640578 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM registry.hub.docker.com/library/golang:1.18 as builder
+FROM registry.hub.docker.com/library/golang:1.19.5 as builder
 WORKDIR /workspace
 COPY . .
 ENV GOOS linux
@@ -9,11 +9,10 @@ RUN go mod vendor && \
 
 # Use golang image
 # needs go to compile the plugin system
-FROM registry.hub.docker.com/library/golang:1.18
+FROM registry.hub.docker.com/library/golang:1.19.5
 ENV CGO_ENABLED 1
 COPY --from=builder /bin/nc /bin/nc
 COPY --from=builder /workspace/prestd /bin/prestd
-COPY --from=builder /workspace/etc/prest.toml /app/prest.toml
 COPY --from=builder /workspace/etc/entrypoint.sh /app/entrypoint.sh
 COPY --from=builder /workspace/lib /app/lib
 COPY --from=builder /workspace/etc/plugin /app/plugin
diff --git a/adapters/postgres/internal/connection/conn.go b/adapters/postgres/internal/connection/conn.go
index de3fe8d..c5cc295 100644
--- a/adapters/postgres/internal/connection/conn.go
+++ b/adapters/postgres/internal/connection/conn.go
@@ -36,20 +36,20 @@ func GetURI(DBName string) string {
 		DBName,
 		config.PrestConf.PGHost,
 		config.PrestConf.PGPort,
-		config.PrestConf.SSLMode,
+		config.PrestConf.PGSSLMode,
 		config.PrestConf.PGConnTimeout)
 
 	if config.PrestConf.PGPass != "" {
 		dbURI += " password=" + config.PrestConf.PGPass
 	}
-	if config.PrestConf.SSLCert != "" {
-		dbURI += " sslcert=" + config.PrestConf.SSLCert
+	if config.PrestConf.PGSSLCert != "" {
+		dbURI += " sslcert=" + config.PrestConf.PGSSLCert
 	}
-	if config.PrestConf.SSLKey != "" {
-		dbURI += " sslkey=" + config.PrestConf.SSLKey
+	if config.PrestConf.PGSSLKey != "" {
+		dbURI += " sslkey=" + config.PrestConf.PGSSLKey
 	}
-	if config.PrestConf.SSLRootCert != "" {
-		dbURI += " sslrootcert=" + config.PrestConf.SSLRootCert
+	if config.PrestConf.PGSSLRootCert != "" {
+		dbURI += " sslrootcert=" + config.PrestConf.PGSSLRootCert
 	}
 
 	return dbURI
diff --git a/adapters/postgres/postgres.go b/adapters/postgres/postgres.go
index 8a4fd10..67985b4 100644
--- a/adapters/postgres/postgres.go
+++ b/adapters/postgres/postgres.go
@@ -87,6 +87,11 @@ func (s *Stmt) Prepare(db *sqlx.DB, tx *sql.Tx, SQL string) (statement *sql.Stmt
 // Load postgres
 func Load() {
 	config.PrestConf.Adapter = &Postgres{}
+
+	if connection.GetDatabase() == "" {
+		connection.SetDatabase(config.PrestConf.PGDatabase)
+	}
+
 	db, err := connection.Get()
 	if err != nil {
 		log.Fatal(err)
@@ -95,7 +100,6 @@ func Load() {
 	if err != nil {
 		log.Fatal(err)
 	}
-	config.PrestConf.Adapter.SetDatabase(config.PrestConf.PGDatabase)
 }
 
 func init() {
diff --git a/config/config.go b/config/config.go
index 798f018..f4502e4 100644
--- a/config/config.go
+++ b/config/config.go
@@ -1,7 +1,6 @@
 package config
 
 import (
-	"fmt"
 	"net/url"
 	"os"
 	"path/filepath"
@@ -54,6 +53,7 @@ type ExposeConf struct {
 
 // Prest basic config
 type Prest struct {
+	Version              int
 	AuthEnabled          bool
 	AuthSchema           string
 	AuthTable            string
@@ -71,6 +71,10 @@ type Prest struct {
 	PGPass               string
 	PGDatabase           string
 	PGURL                string
+	PGSSLMode            string
+	PGSSLCert            string
+	PGSSLKey             string
+	PGSSLRootCert        string
 	ContextPath          string
 	SSLMode              string
 	SSLCert              string
@@ -104,13 +108,13 @@ type Prest struct {
 
 var (
 	// PrestConf config variable
-	PrestConf   *Prest
-	configFile  string
-	defaultFile = "./prest.toml"
+	PrestConf      *Prest
+	configFile     string
+	defaultCfgFile = "./prest.toml"
 )
 
 func viperCfg() {
-	configFile = getDefaultPrestConf(os.Getenv("PREST_CONF"))
+	configFile = getPrestConfFile(os.Getenv("PREST_CONF"))
 
 	dir, file := filepath.Split(configFile)
 	file = strings.TrimSuffix(file, filepath.Ext(file))
@@ -121,6 +125,7 @@ func viperCfg() {
 	viper.AddConfigPath(dir)
 	viper.SetConfigName(file)
 	viper.SetConfigType("toml")
+
 	viper.SetDefault("auth.enabled", false)
 	viper.SetDefault("auth.username", "username")
 	viper.SetDefault("auth.password", "password")
@@ -128,33 +133,45 @@ func viperCfg() {
 	viper.SetDefault("auth.table", "prest_users")
 	viper.SetDefault("auth.encrypt", "MD5")
 	viper.SetDefault("auth.type", "body")
+
 	viper.SetDefault("http.host", "0.0.0.0")
 	viper.SetDefault("http.port", 3000)
 	viper.SetDefault("http.timeout", 60)
+
 	viper.SetDefault("pg.host", "127.0.0.1")
 	viper.SetDefault("pg.port", 5432)
-	viper.SetDefault("ssl.mode", "require")
+	viper.SetDefault("pg.database", "prest")
+	viper.SetDefault("pg.user", "postgres")
+	viper.SetDefault("pg.pass", "postgres")
 	viper.SetDefault("pg.maxidleconn", 0) // avoids db memory leak on req timeout
 	viper.SetDefault("pg.maxopenconn", 10)
 	viper.SetDefault("pg.conntimeout", 10)
 	viper.SetDefault("pg.single", true)
 	viper.SetDefault("pg.cache", true)
-	viper.SetDefault("debug", false)
+	viper.SetDefault("pg.ssl.mode", "require")
+	viper.SetDefault("ssl.mode", "require")
+
 	viper.SetDefault("jwt.default", true)
 	viper.SetDefault("jwt.algo", "HS256")
 	viper.SetDefault("jwt.whitelist", []string{"/auth"})
+
 	viper.SetDefault("cors.allowheaders", []string{"Content-Type"})
 	viper.SetDefault("cors.allowmethods", []string{"GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS"})
 	viper.SetDefault("cors.alloworigin", []string{"*"})
 	viper.SetDefault("cors.allowcredentials", true)
-	viper.SetDefault("context", "/")
+
 	viper.SetDefault("https.mode", false)
 	viper.SetDefault("https.cert", "/etc/certs/cert.crt")
 	viper.SetDefault("https.key", "/etc/certs/cert.key")
+
 	viper.SetDefault("cache.enabled", false)
 	viper.SetDefault("cache.time", 10)
 	viper.SetDefault("cache.storagepath", "./")
 	viper.SetDefault("cache.sufixfile", ".cache.prestd.db")
+
+	viper.SetDefault("version", 1)
+	viper.SetDefault("debug", false)
+	viper.SetDefault("context", "/")
 	viper.SetDefault("pluginpath", "./lib")
 	viper.SetDefault("expose.enabled", false)
 	viper.SetDefault("expose.tables", true)
@@ -168,21 +185,24 @@ func viperCfg() {
 	viper.SetDefault("queries.location", filepath.Join(hDir, "queries"))
 }
 
-func getDefaultPrestConf(prestConf string) string {
-	if prestConf == "" {
-		return defaultFile
+func getPrestConfFile(prestConf string) string {
+	if prestConf != "" {
+		return prestConf
 	}
-	return prestConf
+	return defaultCfgFile
 }
 
 // Parse pREST config
-func Parse(cfg *Prest) (err error) {
-	err = viper.ReadInConfig()
+func Parse(cfg *Prest) {
+	err := viper.ReadInConfig()
 	if err != nil {
 		if _, ok := err.(viper.ConfigFileNotFoundError); ok {
-			return fmt.Errorf("file %s not found, aborting", configFile)
+			log.Warningf(
+				"file '%s' not found, falling back to default settings\n",
+				configFile)
+			cfg.SSLMode = "disable"
 		}
-		return
+		log.Warningf("read env config error: %v\n", err)
 	}
 	cfg.AuthEnabled = viper.GetBool("auth.enabled")
 	cfg.AuthSchema = viper.GetString("auth.schema")
@@ -194,6 +214,7 @@ func Parse(cfg *Prest) (err error) {
 	cfg.AuthType = viper.GetString("auth.type")
 	cfg.HTTPHost = viper.GetString("http.host")
 	cfg.HTTPPort = viper.GetInt("http.port")
+	portFromEnv(cfg)
 	cfg.HTTPTimeout = viper.GetInt("http.timeout")
 	cfg.PGURL = viper.GetString("pg.url")
 	cfg.PGHost = viper.GetString("pg.host")
@@ -201,22 +222,25 @@ func Parse(cfg *Prest) (err error) {
 	cfg.PGUser = viper.GetString("pg.user")
 	cfg.PGPass = viper.GetString("pg.pass")
 	cfg.PGDatabase = viper.GetString("pg.database")
-	cfg.SSLMode = viper.GetString("ssl.mode")
+	cfg.PGSSLMode = viper.GetString("pg.ssl.mode")
+	cfg.PGSSLKey = viper.GetString("pg.ssl.key")
+	cfg.PGSSLCert = viper.GetString("pg.ssl.cert")
+	cfg.PGSSLRootCert = viper.GetString("pg.ssl.rootcert")
+
+	// only use value if file is present
+	if cfg.SSLMode == "" {
+		cfg.SSLMode = viper.GetString("ssl.mode")
+	}
 	cfg.SSLCert = viper.GetString("ssl.cert")
 	cfg.SSLKey = viper.GetString("ssl.key")
 	cfg.SSLRootCert = viper.GetString("ssl.rootcert")
-	err = portFromEnv(cfg)
-	if err != nil {
-		return
-	}
+
+	parseSSLData(cfg)
 	if os.Getenv("DATABASE_URL") != "" {
 		// cloud factor support: https://devcenter.heroku.com/changelog-items/438
 		cfg.PGURL = os.Getenv("DATABASE_URL")
 	}
-	err = parseDatabaseURL(cfg)
-	if err != nil {
-		return
-	}
+	parseDatabaseURL(cfg)
 	cfg.PGMaxIdleConn = viper.GetInt("pg.maxidleconn")
 	cfg.PGMaxOpenConn = viper.GetInt("pg.maxopenconn")
 	cfg.PGConnTimeout = viper.GetInt("pg.conntimeout")
@@ -251,48 +275,51 @@ func Parse(cfg *Prest) (err error) {
 	var cacheendpoints []CacheEndpoint
 	err = viper.UnmarshalKey("cache.endpoints", &cacheendpoints)
 	if err != nil {
-		return
+		log.Errorln("could not unmarshal cache endpoints")
 	}
 	cfg.Cache.Endpoints = cacheendpoints
 	var tablesconf []TablesConf
 	err = viper.UnmarshalKey("access.tables", &tablesconf)
 	if err != nil {
-		return
+		log.Errorln("could not unmarshal access tables")
 	}
 	cfg.AccessConf.Tables = tablesconf
-	return
+
+	cfg.Version = viper.GetInt("version")
 }
 
 // Load configuration
 func Load() {
 	viperCfg()
 	PrestConf = &Prest{}
-	err := Parse(PrestConf)
-	if err != nil {
-		panic(err)
-	}
-	if _, err = os.Stat(PrestConf.QueriesPath); os.IsNotExist(err) {
+	Parse(PrestConf)
+	if _, err := os.Stat(PrestConf.QueriesPath); os.IsNotExist(err) {
 		if err = os.MkdirAll(PrestConf.QueriesPath, 0700); os.IsNotExist(err) {
-			log.Errorf("Queries directory %s is not created", PrestConf.QueriesPath)
+			log.Errorf("Queries directory %s was not created\n", PrestConf.QueriesPath)
 		}
 	}
 }
 
-func parseDatabaseURL(cfg *Prest) (err error) {
+// parseDatabaseURL tries to get from URL the DB configs
+func parseDatabaseURL(cfg *Prest) {
 	if cfg.PGURL == "" {
+		log.Debugln("no db url found, skipping")
 		return
 	}
 	// Parser PG URL, get database connection via string URL
-	u, errPerse := url.Parse(cfg.PGURL)
-	if errPerse != nil {
-		err = errPerse
+	u, err := url.Parse(cfg.PGURL)
+	if err != nil {
+		log.Errorf("cannot parse db url, err: %v\n", err)
 		return
 	}
 	cfg.PGHost = u.Hostname()
 	if u.Port() != "" {
-		pgPort, PortErr := strconv.Atoi(u.Port())
-		if PortErr != nil {
-			return PortErr
+		pgPort, err := strconv.Atoi(u.Port())
+		if err != nil {
+			log.Errorf(
+				"cannot parse db url port '%v', falling back to default values\n",
+				u.Port())
+			return
 		}
 		cfg.PGPort = pgPort
 	}
@@ -305,18 +332,49 @@ func parseDatabaseURL(cfg *Prest) (err error) {
 	if u.Query().Get("sslmode") != "" {
 		cfg.SSLMode = u.Query().Get("sslmode")
 	}
-	return
 }
 
-func portFromEnv(cfg *Prest) (err error) {
+func portFromEnv(cfg *Prest) {
 	if os.Getenv("PORT") == "" {
+		log.Debugln("could not find PORT in env")
 		return
 	}
 	// cloud factor support: https://help.heroku.com/PPBPA231/how-do-i-use-the-port-environment-variable-in-container-based-apps
 	HTTPPort, err := strconv.Atoi(os.Getenv("PORT"))
 	if err != nil {
+		log.Debugln("could not find PORT in env")
 		return
 	}
 	cfg.HTTPPort = HTTPPort
-	return
+}
+
+// parseSSLData favors the config according to the version used
+// v1 uses PG from old config
+// v2 uses PG from new config (env/toml)
+//
+// todo: deprecate v1
+func parseSSLData(cfg *Prest) {
+	if cfg.Version <= 1 {
+		parseSSLV1Data(cfg)
+		return
+	}
+	log.Warningln(`
+You are using v2 of prestd configs, please note that v1 postgres SSL environment variables are ignored and you have to set them correctly.
+
+When using v2 the following environment variables will be ignored: PREST_SSL_MODE, PREST_SSL_CERT, PREST_SSL_KEY, PREST_SSL_ROOTCERT
+
+View more at https://docs.prestd.com/prestd/deployment/server-configuration`)
+}
+
+func parseSSLV1Data(cfg *Prest) {
+	log.Warningln(`
+You are using v1 of prestd configs, please migrate to v2. 
+
+v1 will be deprecated soon.
+
+View more at https://docs.prestd.com/prestd/deployment/server-configuration`)
+	cfg.PGSSLMode = cfg.SSLMode
+	cfg.PGSSLKey = cfg.SSLKey
+	cfg.PGSSLCert = cfg.SSLCert
+	cfg.PGSSLRootCert = cfg.SSLRootCert
 }
diff --git a/docker-compose.yml b/docker-compose.yml
index dff9a4e..468fbe0 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -5,9 +5,9 @@ services:
     volumes:
       - "./data/postgres:/var/lib/postgresql/data"
     environment:
-      - POSTGRES_USER=prest
       - POSTGRES_DB=prest
-      - POSTGRES_PASSWORD=prest
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=postgres
     ports:
       - "5432:5432"
     healthcheck:
@@ -16,18 +16,14 @@ services:
       retries: 3
   prest:
     build: .
+    restart: on-failure
     links:
       - "postgres:postgres"
     environment:
-      - PREST_DEBUG=true # remove comment for enable DEBUG mode (disable JWT)
+      - PREST_DEBUG=true # remove comment to disable DEBUG mode
       - PREST_PG_HOST=postgres
-      - PREST_PG_USER=prest
-      - PREST_PG_PASS=prest
-      - PREST_PG_DATABASE=prest
-      - PREST_PG_PORT=5432
-      - PREST_CACHE=false
-      - PREST_JWT_DEFAULT=false # remove if need jwt
-      - PREST_SSL_MODE=disable
+      - PREST_PG_CACHE=false
+      - PREST_JWT_DEFAULT=false # toggle to use jwt
       - PREST_CACHE_ENABLED=false
     depends_on:
       postgres:
diff --git a/docs/deployment/server-configuration.md b/docs/deployment/server-configuration.md
index 7dd3b24..5b1d5f0 100644
--- a/docs/deployment/server-configuration.md
+++ b/docs/deployment/server-configuration.md
@@ -4,42 +4,47 @@ date: 2017-08-30T19:05:46-03:00
 weight: 2
 ---
 
-The _**prestd**_ configuration is via an _environment variable_ or _toml_ file.
+The _**prestd**_ configuration is via an _environment variable_ or _toml_ file. Starting from version `v1.2.0` it will be possible to use `prestd` without any _environment variable_ or the _toml_ file, but the configurations used will be the described in the default column bellow.
 
 ## Environment variables
 
 | var | default | description |
 | --- | --- | --- |
-| PREST\_CONF | ./prest.conf | |
-| PREST\_MIGRATIONS | ./migrations | |
-| PREST\_QUERIES_LOCATION | ./queries | |
-| PREST\_HTTP_HOST | 0.0.0.0 | |
-| PREST\_HTTP_PORT or **PORT** | 3000 | PORT is cloud factor, _when declaring this variable overwritten PREST\_HTTP_PORT |
-| PREST\_PG_HOST | 127.0.0.1 | |
-| PREST\_PG_USER | | |
-| PREST\_PG_PASS | | |
-| PREST\_PG_DATABASE | | |
-| PREST\_PG_PORT | 5432 | |
-| PREST\_PG_URL or **DATABASE\_URL** | | cloud factor, _when declaring this variable all the previous connection fields are overwritten_ |
-| PREST\_CACHE_ENABLED | false | embedded cache system |
-| PREST\_CACHE_TIME | 10 | TTL in minute (time to live) |
-| PREST\_CACHE_STORAGEPATH | ./ | path where the cache file will be created |
-| PREST\_CACHE_SUFIXFILE | .cache.prestd.db | suffix of the name of the file that is created |
-| PREST\_JWT_KEY | | |
-| PREST\_JWT_ALGO | HS256 | |
-| PREST\_JWT_WHITELIST | [/auth] | |
-| PREST\_AUTH_ENABLED | false | |
-| PREST\_AUTH_ENCRYPT | MD5 | |
-| PREST\_AUTH_TYPE | body | |
-| PREST\_AUTH_SCHEMA | public | |
-| PREST\_AUTH_TABLE | prest_users | |
-| PREST\_AUTH_USERNAME | username | |
-| PREST\_AUTH_PASSWORD | password | |
-| PREST\_SSL_MODE | require | |
-| PREST\_SSL_CERT | | |
-| PREST\_SSL_KEY | | |
-| PREST\_SSL_ROOTCERT | | |
-| PREST\_PLUGINPATH | ./lib | path to plugin storage `.so`  |
+| `PREST_VERSION` | 1 | version used for environment variables, v2 introduces better naming for SSL pg connection |
+| `PREST_CONF` | ./prest.conf | |
+| `PREST_MIGRATIONS` | ./migrations | |
+| `PREST_QUERIES_LOCATION` | ./queries | |
+| `PREST_HTTP_HOST` | 0.0.0.0 | |
+| `PREST_HTTP_PORT` or **PORT** | `3000` | `PORT` is for cloud factor, _when declared this variable overwrittes_ `PREST_HTTP_PORT` |
+| `PREST_PG_HOST` | `127.0.0.1` | host used to connect |
+| `PREST_PG_USER` | `postgres` | user used to connect |
+| `PREST_PG_PASS` | `postgres` | password used to connect |
+| `PREST_PG_DATABASE` | `prest` | database name used to connect |
+| `PREST_PG_PORT` | `5432` | |
+| `PREST_PG_URL` or **DATABASE\_URL** | | cloud factor, _when declaring this variable all the previous connection fields are overwritten_ |
+| `PREST_CACHE_ENABLED` | false | embedded cache system |
+| `PREST_CACHE_TIME` | 10 | TTL in minute (time to live) |
+| `PREST_CACHE_STORAGEPATH` | ./ | path where the cache file will be created |
+| `PREST_CACHE_SUFIXFILE` | .cache.prestd.db | suffix of the name of the file that is created |
+| `PREST_JWT_KEY` | | |
+| `PREST_JWT_ALGO` | HS256 | |
+| `PREST_JWT_WHITELIST` | [/auth] | |
+| `PREST_AUTH_ENABLED` | false | |
+| `PREST_AUTH_ENCRYPT` | MD5 | |
+| `PREST_AUTH_TYPE` | body | |
+| `PREST_AUTH_SCHEMA` | public | |
+| `PREST_AUTH_TABLE` | prest_users | |
+| `PREST_AUTH_USERNAME` | username | |
+| `PREST_AUTH_PASSWORD` | password | |
+| `PREST_SSL_MODE` | require | SSL mode used to connect to postgres, not related to server SSL |
+| `PREST_SSL_CERT` | | SSL certificate used to connect to postgres, not related to server SSL |
+| `PREST_SSL_KEY` | | SSL key used to connect to postgres, not related to server SSL |
+| `PREST_SSL_ROOTCERT` | | SSL root certificate used to connect to postgres, not related to server SSL |
+| `PREST_PG_SSL_MODE` | require | v2 of configuration envs, is the postgres connection SSL mode |
+| `PREST_PG_SSL_CERT` | | v2 of configuration envs, is the postgres connection SSL certificate |
+| `PREST_PG_SSL_KEY` | | v2 of configuration envs, is the postgres connection SSL key |
+| `PREST_PG_SSL_ROOTCERT` | | v2 of configuration envs, is the postgres connection SSL root certificate |
+| `PREST_PLUGINPATH` | ./lib | path to plugin storage `.so`  |
 
 ## TOML
 
@@ -195,12 +200,15 @@ If you want to disable just the database listing:
 
 ## SSL
 
-There is 4 options to set on ssl mode:
+There are 4 options to set on ssl mode:
+
+| Name | Description | Comment |
+| --- | --- | --- |
+| `require` | Always SSL, is the default value | skips SSL verification step |
+| `disable` | SSL off | also used when prestd is started without a `toml` file |
+| `verify-ca` | Always SSL | verifies that the certificate presented is signed by a trusted CA |
+| `verify-full` | Always SSL | verifies that the certificate presented is signed by a trusted CA and the server host name matches the one in the certificate |
 
-* `require` - Always SSL (skip verification) **by default**
-* `disable` - SSL off
-* `verify-ca` - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
-* `verify-full` - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)
 
 ## Debug Mode
 
@@ -212,13 +220,15 @@ PREST_DEBUG=true
 
 ## Single mode
 
-While serving multiple databases over the same API with pREST is doable, it's by default a single database setup. This is this way to prevent unwanted behavior that may make prest instable for users, in order to change that It's possible to pass a variable on your `toml` file to disable it under the `[pg]` tag as shown bellow.
+Serving multiple databases over the same API with `prestd` is doable, but it is not currently supported. Thus it was introduced by default the `single` configuration, it can be disabled by the following config in the `toml` file:
 
 ```toml
 [pg]
     single = false
 ```
 
+Since `v1.1.2` it is a lot safer to use multiple databases, but not yet in the ideal state of security that we want, so use it in your own risk.
+
 ## CORS support
 
 **Cross-Origin Resource Sharing**
diff --git a/etc/prest.toml b/etc/prest.toml
deleted file mode 100644
index e5ba0de..0000000
--- a/etc/prest.toml
+++ /dev/null
@@ -1,9 +0,0 @@
-[jwt]
-default = false
-
-[pg]
-host = "127.0.0.1"
-user = "prest"
-pass = "prest"
-port = 5432
-database = "prest"


Test patch:
diff --git a/config/config_test.go b/config/config_test.go
index 9db6d01..75a5812 100644
--- a/config/config_test.go
+++ b/config/config_test.go
@@ -22,21 +22,31 @@ func TestLoad(t *testing.T) {
 }
 
 func TestParse(t *testing.T) {
+	t.Run("no envs", func(t *testing.T) {
+		t.Setenv("PREST_CONF", "../notfound.toml")
+		viperCfg()
+		cfg := &Prest{}
+		Parse(cfg)
+		require.Equal(t, 3000, cfg.HTTPPort)
+		require.Equal(t, "prest-test", cfg.PGDatabase)
+		require.Equal(t, "postgres", cfg.PGHost)
+		require.Equal(t, "postgres", cfg.PGUser)
+		require.Equal(t, "postgres", cfg.PGPass)
+		require.Equal(t, true, cfg.PGCache)
+		require.Equal(t, true, cfg.SingleDB)
+		require.Equal(t, "disable", cfg.SSLMode)
+		require.Equal(t, false, cfg.Debug)
+		require.Equal(t, 1, cfg.Version)
+		require.Equal(t, true, cfg.AccessConf.Restrict)
+	})
+
 	t.Run("PREST_CONF", func(t *testing.T) {
 		t.Setenv("PREST_CONF", "../testdata/prest.toml")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 3000, cfg.HTTPPort)
-
-		var expected string
-		expected = os.Getenv("PREST_PG_DATABASE")
-		if len(expected) == 0 {
-			expected = "prest"
-		}
-
-		require.Equal(t, expected, cfg.PGDatabase)
+		require.Equal(t, "prest-test", cfg.PGDatabase)
 	})
 
 	t.Run("PREST_HTTP_PORT and unset PREST_JWT_DEFAULT", func(t *testing.T) {
@@ -44,8 +54,7 @@ func TestParse(t *testing.T) {
 		os.Unsetenv("PREST_JWT_DEFAULT")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 4000, cfg.HTTPPort)
 		require.True(t, cfg.EnableDefaultJWT)
 	})
@@ -55,8 +64,7 @@ func TestParse(t *testing.T) {
 		t.Setenv("PREST_JWT_DEFAULT", "false")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 3000, cfg.HTTPPort)
 		require.False(t, cfg.EnableDefaultJWT)
 	})
@@ -65,8 +73,7 @@ func TestParse(t *testing.T) {
 		t.Setenv("PREST_CONF", "")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 3000, cfg.HTTPPort)
 	})
 
@@ -74,8 +81,7 @@ func TestParse(t *testing.T) {
 		t.Setenv("PREST_JWT_KEY", "s3cr3t")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, "s3cr3t", cfg.JWTKey)
 		require.Equal(t, "HS256", cfg.JWTAlgo)
 	})
@@ -84,34 +90,24 @@ func TestParse(t *testing.T) {
 		t.Setenv("PREST_JWT_ALGO", "HS512")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, "HS512", cfg.JWTAlgo)
 	})
 }
 
-func TestGetDefaultPrestConf(t *testing.T) {
+func Test_getPrestConfFile(t *testing.T) {
 	testCases := []struct {
 		name      string
 		prestConf string
-		result    string
+		expected  string
 	}{
 		{"custom config", "../prest.toml", "../prest.toml"},
 		{"default config", "", "./prest.toml"},
 	}
 	for _, tc := range testCases {
 		t.Run(tc.name, func(t *testing.T) {
-			cfg := getDefaultPrestConf(tc.prestConf)
-			if tc.prestConf == "" {
-				if cfg != "./prest.toml" {
-					t.Errorf("expected %v, but got %v", tc.result, cfg)
-				}
-			} else {
-				if cfg != tc.result || cfg == "./prest.toml" {
-					t.Errorf("expected %v, but got %v", tc.result, cfg)
-				}
-			}
-
+			cfg := getPrestConfFile(tc.prestConf)
+			require.Equal(t, tc.expected, cfg)
 		})
 	}
 }
@@ -122,8 +118,7 @@ func TestDatabaseURL(t *testing.T) {
 	t.Run("PREST_PG_URL", func(t *testing.T) {
 		t.Setenv("PREST_PG_URL", "postgresql://user:pass@localhost:1234/mydatabase/?sslmode=disable")
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, "mydatabase", cfg.PGDatabase)
 		require.Equal(t, "localhost", cfg.PGHost)
 		require.Equal(t, 1234, cfg.PGPort)
@@ -135,8 +130,8 @@ func TestDatabaseURL(t *testing.T) {
 	t.Run("DATABASE_URL", func(t *testing.T) {
 		t.Setenv("DATABASE_URL", "postgresql://cloud:cloudPass@localhost:5432/CloudDatabase/?sslmode=disable")
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
+		require.Equal(t, "CloudDatabase", cfg.PGDatabase)
 		require.Equal(t, 5432, cfg.PGPort)
 		require.Equal(t, "cloud", cfg.PGUser)
 		require.Equal(t, "cloudPass", cfg.PGPass)
@@ -150,18 +145,16 @@ func TestHTTPPort(t *testing.T) {
 	t.Run("set PORT", func(t *testing.T) {
 		t.Setenv("PORT", "8080")
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 8080, cfg.HTTPPort)
 	})
 
 	t.Run("set PREST_HTTP_PORT", func(t *testing.T) {
-		t.Setenv("PREST_HTTP_PORT", "3000")
+		t.Setenv("PREST_HTTP_PORT", "3030")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
-		require.Equal(t, 3000, cfg.HTTPPort)
+		Parse(cfg)
+		require.Equal(t, 3030, cfg.HTTPPort)
 	})
 
 	t.Run("set PORT and PREST_HTTP_PORT", func(t *testing.T) {
@@ -169,16 +162,14 @@ func TestHTTPPort(t *testing.T) {
 		t.Setenv("PREST_HTTP_PORT", "3000")
 		viperCfg()
 		cfg := &Prest{}
-		err := Parse(cfg)
-		require.NoError(t, err)
+		Parse(cfg)
 		require.Equal(t, 8080, cfg.HTTPPort)
 	})
 }
 
 func Test_parseDatabaseURL(t *testing.T) {
 	c := &Prest{PGURL: "postgresql://user:pass@localhost:5432/mydatabase/?sslmode=require"}
-	err := parseDatabaseURL(c)
-	require.NoError(t, err)
+	parseDatabaseURL(c)
 	require.Equal(t, "mydatabase", c.PGDatabase)
 	require.Equal(t, 5432, c.PGPort)
 	require.Equal(t, "user", c.PGUser)
@@ -186,18 +177,33 @@ func Test_parseDatabaseURL(t *testing.T) {
 	require.Equal(t, "require", c.SSLMode)
 
 	// errors
+	// todo: make this default on any problem
 	c = &Prest{PGURL: "postgresql://user:pass@localhost:port/mydatabase/?sslmode=require"}
-	err = parseDatabaseURL(c)
-	require.Error(t, err)
+	parseDatabaseURL(c)
+	require.Equal(t, "", c.PGDatabase)
+
+	c = &Prest{PGURL: `invalid%+o`}
+	parseDatabaseURL(c)
+	require.Equal(t, "", c.PGDatabase)
+	require.Equal(t, "", c.PGUser)
 }
 
-func Test_portFromEnv(t *testing.T) {
+func Test_portFromEnv_Error(t *testing.T) {
 	c := &Prest{}
 
 	t.Setenv("PORT", "PORT")
 
-	err := portFromEnv(c)
-	require.Error(t, err)
+	portFromEnv(c)
+	// this should be zero as this only modifies c.HTTPPort when the "PORT" env is set
+	require.Equal(t, 0, c.HTTPPort)
+}
+
+func Test_portFromEnv_OK(t *testing.T) {
+	c := &Prest{}
+
+	t.Setenv("PORT", "1234")
+	portFromEnv(c)
+	require.Equal(t, 1234, c.HTTPPort)
 }
 
 func Test_Auth(t *testing.T) {
@@ -205,8 +211,7 @@ func Test_Auth(t *testing.T) {
 
 	viperCfg()
 	cfg := &Prest{}
-	err := Parse(cfg)
-	require.NoError(t, err)
+	Parse(cfg)
 	require.Equal(t, false, cfg.AuthEnabled)
 	require.Equal(t, "public", cfg.AuthSchema)
 	require.Equal(t, "prest_users", cfg.AuthTable)
@@ -227,8 +232,7 @@ func Test_ExposeDataConfig(t *testing.T) {
 
 	viperCfg()
 	cfg := &Prest{}
-	err := Parse(cfg)
-	require.NoError(t, err)
+	Parse(cfg)
 	require.Equal(t, true, cfg.ExposeConf.Enabled)
 	require.Equal(t, false, cfg.ExposeConf.DatabaseListing)
 	require.Equal(t, false, cfg.ExposeConf.SchemaListing)