CGM_Public/pretix_original
2
0
Fork 1
mirror of https://github.com/pretix/pretix.git synced 2026-05-05 15:14:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove MariaDB support (#3381)

Browse Source
This commit is contained in:
Raphael Michel
2023-06-05 18:25:20 +02:00
committed by GitHub
parent 446c55dc89
commit f4b437e92b
17 changed files with 25 additions and 122 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/pretix/control/templates/pretixcontrol/base.html
View File

@@ -423,17 +423,6 @@
</div>
{% endif %}
{% if "mysql" in settings.DATABASES.default.ENGINE and not request.organizer %}
<div class="alert alert-warning">
{% blocktrans trimmed %}
You are using MySQL or MariaDB as your database backend for pretix.
Starting in pretix 5.0, these will no longer be supported and you will need to migrate to PostgreSQL.
Please see the pretix administrator documentation for a migration guide, and the pretix 4.16
release notes for more information.
{% endblocktrans %}
</div>
{% endif %}
{% if debug_warning %}
<div class="alert alert-danger">
{% trans "pretix is running in debug mode. For security reasons, please never run debug mode on a production instance." %}

4
src/pretix/control/views/search.py
View File

@@ -93,7 +93,7 @@ class OrderSearch(PaginationMixin, ListView):
if self.filter_form.use_query_hack():
"""
We need to work around a bug in PostgreSQL's (and likely MySQL's) query plan optimizer here.
We need to work around a bug in PostgreSQL's query plan optimizer here.
The database lacks statistical data to predict how common our search filter is and therefore
assumes that it is cheaper to first ORDER *all* orders in the system (since we got an index on
datetime), then filter out with a full scan until OFFSET/LIMIT condition is fulfilled. If we
@@ -167,7 +167,7 @@ class PaymentSearch(PaginationMixin, ListView):
if self.filter_form.cleaned_data.get('query'):
"""
We need to work around a bug in PostgreSQL's (and likely MySQL's) query plan optimizer here.
We need to work around a bug in PostgreSQL's query plan optimizer here.
The database lacks statistical data to predict how common our search filter is and therefore
assumes that it is cheaper to first ORDER *all* orders in the system (since we got an index on
datetime), then filter out with a full scan until OFFSET/LIMIT condition is fulfilled. If we