MySQL

Unknown database type enum requested

Bei der Installation einer Shopware App, die Entities (Resources/entities.xml) enthält, wird mir bei Shopware 6.4 mitunter ein lapidares Unknown database type enum requested, MariaDb1027Platform may not support it. auf der Konsole entgegen gehustet. Das tritt auf, wenn man MariaDB benutzt und Plugins installiert sind, die Datenbanktabellen erstellen, die Felder des Typs EUNUM haben. Shopware scheint sich hier wohl Doctrine zu bedienen um Entities aus der XML Datei der App anzulegen.

Wenn es sich um eine fremdes Plugin mit den betroffenen Tabellen handelt, mache ich es mir idR. einfach und wandle die ENUM Spalten in ausreichend große VARCHAR Spalten um. Und dann klappt auch der Spaß mit der App Aktivierung.

Es ist per SQL Query relativ einfach die "schuldigen" Tabellen und Spalten zu finden:

select col.table_schema as database_name,
     col.table_name,
     col.ordinal_position as column_id,
     col.column_name,
     col.data_type,
     trim(leading 'enum' from col.column_type) as enum_values
from information_schema.columns col
join information_schema.tables tab 
    on tab.table_schema = col.table_schema
        and tab.table_name = col.table_name
        and tab.table_type = 'BASE TABLE'
where col.data_type in ('enum')
    and col.table_schema not in (
        'information_schema', 
        'sys',
        'performance_schema', 
        'mysql'
    )
    and col.table_schema = 'Meine_Shopware_Datenbank' 
order by col.table_schema,
    col.table_name,
    col.ordinal_position;

Meine_Shopware_Datenbank muss natürlich durch den entsprechenden Namen der Shopware DB ausgetauscht werden.

Journal-Tags aus Exif Daten

Seit einer Weile speichere ich auch die Exif Daten der Fotos in der Datenbank und nun habe ich mir mal die Zeit genommen und für jeden Post mit einem Foto, das die Infos hat, Tags für Kamera und Objektiv zu generieren. Das fängt leider erst im Oktober 2021 an. Das sind nicht einmal 2 Jahren von insgesamt 22 Jahren.

Ich bin mir nicht sicher, ob ich den Rest manuell taggen möchte...

Hier sind auf jeden Fall die nigelnagelneuen Tags:

Und natürlicherweise auch in der Wolke zu finden.

SQL zum Erstellen der Relationen zwischen Tag und Post ist dank JSON_EXTRACT relativ einfach:

REPLACE INTO journal_entry_tag (entryId, tagId) 
  SELECT DISTINCT je.id, 494  
  FROM journal_image ji 
  INNER JOIN journal_entry je ON je.content LIKE concat('%',ji.url,'%') 
  WHERE REPLACE(JSON_EXTRACT(ji.exif, '$.lens'),'"','') LIKE 'Zeiss Planar%'; 
-- wobei 494 die Id vom Tag "Zeiss Planar T* 1.4/50 ZF.2" ist

Da soll mal jemand sagen: ein Blog wäre kein Hobby ;)

Wieviel Spaß ein kleiner Query doch machen kann.

Wieviel Spaß ein kleiner Query doch machen kann. Auf den Tag-Seiten gibt es im Kopf nun einer Liste verwandter Tags. Was mich allerdings immer Wieder daran erinnert, dass die Tags aufgrund des Alters vom Blog etwas ungepflegt sind. Aber die langen Winterabende werden kommen.

SELECT t.*, COUNT(*) AS anz
FROM journal_tag t 
LEFT JOIN journal_entry_tag et ON et.tagId = t.id 
LEFT JOIN journal_entry e ON et.entryId = e.id
WHERE 
  et.entryId IN (
    SELECT entryId FROM journal_entry_tag WHERE tagId = :tagid
  ) AND et.tagId != :tagid AND t.scheme = 'tag'
  AND e.status = 'published'
GROUP BY t.id 
-- HAVING anz > 1 Wenn man mag
ORDER by anz DESC;

Order by Enum

Jetzt bin ich seit gut einer Millionen Jahre Entwickler und arbeite mit SQL Datenbanken. Aber jetzt ist mir erst aufgefallen, dass bei einem ORDER BY auf ein Enum Feld nicht alphanumerisch sortiert wird sondern nach der Reihenfolge in der Definition des Enum.

SELECT * FROM table ORDER BY CAST(col AS CHAR);

vs.

SELECT * FROM table ORDER BY col;

wenn

col enum('b','a') NOT NULL DEFAULT 'b'

MySQL Next Insert ID

Wesentlich eleganter als einen leeren Datensatz einzufügen und dann die lastInsertId zu nehmen, ist es den Status der Tabelle abzufragen, denn der enthält die nächste Auto Increment Id. 

SHOW TABLE STATUS WHERE name = 'yourTableName';

Liefert im Result den Wert in Feld Auto_increment. 

SELECT `AUTO_INCREMENT` FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'YourDataBaseName' 
AND TABLE_NAME = 'yourTableName';

Liefert dann nur den einen Wert.

Querious

Ja, irgendwo war Heute ein Tag der Veränderung. Nachdem ich nun über etliche Jahre Sequel Pro als grafisches Frontend für MySQL benutzt habe, kam ich in jüngster Vergangenheit nicht umher eine gewisse Stagnation in der Weiterentwicklung zu beobachten. Erst gab es noch regelmäßige Nightlies, die mal mehr und mal weniger gut funktioniert haben. Aber seit einer Weile scheint es auch damit vorbei zu sein. Zu einem Augenblick da die Stabilität auch noch arg zu wünschen übrig lässt. Also musste langsam mal eine Alternativ her. 

TablePlus war die erste Option. Die Liste der unterstützten DB System ist spannend. Dankenswerter Weise ist auch MongoDB darunter. Aber leider ist TablePlus für meine Begriffe etwas zu fancy und auch irgendwie ein wenig anstrengend. 

Die zweite Alternative war Querious 2. Ich mach’s kurz. Querious ist schlichter und einfacher. Und die Shortcuts haben mich überzeugt. 

Als Hintergrund: ich benutze das Frontend nicht um Strukturen zu entwerfen sondern idR. um mal schnell einen Blick auf eine DB zu werfen und Daten zu analysieren. Und vielleicht mal den einen oder anderen Datensatz zu ändern oder einen Query für den einmaligen Gebrauch zu schreiben. Raw SQL Queries im Application Context empfinde ich hingegen als ein No-Go. 

MySQL 4 bei Domainfactory

Na endlich:) Domain Factory, der Hoster meiner Wahl, stellt seinen Kunden nun auf allen skriptfähigen Tarifen MySQL 4.1.14 zur Verfügung. Dabei wird es dem Kunden überlassen, ob eine Datenbank mit MySQL 4 oder weiterhin mit Version 3 betrieben wird.

Ja, nett! Dann kann ich die Tage ja mal sehen, was meine Blog Datenbank zu MySQL 4 sagt.
Endlich boolsche Operatoren in der Volltextsuche. Naja, und ein paar andere Sachen, die endlich möglich werden.