[create-pull-request] automated change

Author: shopwareBot

SUMMARY.md

@@ -479,6 +479,8 @@
     * [Mocking repositories](resources/references/adr/2023-04-01-mocking-repositories.md)
     * [Disable css autoprefixer](resources/references/adr/2023-04-03-disable-css-autoprefixer.md)
     * [Jest test files should be javascript only](resources/references/adr/2023-04-14-jest-test-files-should-be-javascript-only.md)
+    * [Switch to uuidv7](resources/references/adr/2023-05-22-switch-to-uuidv7.md)
+    * [Exception log levels](resources/references/adr/2023-05-25-exception-log-levels.md)
     * [YYYY MM DD template](resources/references/adr/YYYY-MM-DD-template.md)
 
   * [App Reference](resources/references/app-reference/README.md)

resources/references/adr/2023-05-22-switch-to-uuidv7.md

@@ -0,0 +1,39 @@
+---
+title: Switch to UUIDv7
+date: 2023-05-22
+area:  core
+tags: [DAL]
+---
+
+# Switch to UUIDv7
+
+{% hint style="info" %}
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/platform/blob/trunk/adr/2023-05-22-switch-to-uuidv7.md)
+{% endhint %}
+
+## Context
+
+Using UUIDs as primary keys eases the integration of several different datasources,
+but it also brings some performance issues.
+
+Currently, we're using UUIDv4, which is a random UUID the completely random prefix means
+that the B-tree indexes of the database are not very efficient.
+
+UUIDv7 time based prefix is less spread than that of UUIDv4, this helps the database to keep the index more compact.
+It allows the Index to allocate fewer new pages and to keep the index smaller.
+
+## Decision
+
+Considering there is little risk to using UUIDv7, as v4 and v7 share the same
+length and are indistinguishable for shopware, we can switch to v7 without any risk
+of breaking anything.
+
+The effort is also very low as we only need to change the
+implementation of the `Uuid` class. As using UUIDv7 will improve the speed of
+bulk product inserts by about 8 %, we think the effort is worth the measurable and
+theoretical gain.
+
+## Consequences
+
+We will switch to UUIDv7 as default and add performance guides promoting v7.

resources/references/adr/2023-05-25-exception-log-levels.md

@@ -0,0 +1,39 @@
+---
+title: Exception Log Level configuration
+date: 2023-05-25
+area: core
+tags: [core, devops, observability]
+---
+
+# Exception Log Level configuration
+
+{% hint style="info" %}
+This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository.
+You can find the original version [here](https://github.com/shopware/platform/blob/trunk/adr/2023-05-25-exception-log-levels.md)
+{% endhint %}
+
+## Context
+By default every exception that is thrown in the PHP stack and not catched will be logged by the `symfony/monolog-bridge` on `error` level.
+But there are some cases where the exception is caused by clients accessing the API wrong (missing fields etc.) and throwing an `ShopwareHttpException` with a HTTP-Status-Code of 40x is our way of handling such situations and returning a correct HTTP-Status-Code to the client.
+So those cases are in fact no "errors" that need to be analyzed, but are expected given a malformed API request.
+Logging those cases as "errors" produces a lot of noice, which makes it harder to actually find errors in the logs.
+
+For our cloud product we already used a configuration list that configures that some Exception classes should only be logged as notices.
+
+## Decision
+
+We add configuration to the platform that degrades the error level of specific exceptions to notices. This way external hosters can also profit from our classification.
+We use [symfony's `exceptions` configuration](https://symfony.com/doc/current/reference/configuration/framework.html#exceptions) for this.
+
+This has the benefit that for specific projects this configuration could be adjusted, for example for cases where you also controll all clients that access the shop, you may want to log also every client error, just to help debugging the client.
+
+Another solution could be to do the configuration of the log level directly in the exception class either by attributes or a separate method specifying the log level, but that would make overwriting it for a specific project harder, so we stick to the default symfony configuration.
+
+## Consequences
+
+We will add the `exceptions` configuration to the platform, that way the error logging in existing projects might change. But in general we assume that this change is for the better.
+
+Additionally we will need to extend on the default symfony configuration as that is not compatible with our new [domain exceptions](./2022-02-24-domain-exceptions.md) as there are multiple exception cases in one file/class. 
+Therefore we will add a similiar configuration option, that does not rely on the FQCN, but instead we will use the shopware specific `error code` from the shopware exception as that is unique to the exception case.
+
+On a side note we should be able to get rid of most the cloud specific configuration for the exception logging mapping.