Board index Generelles in Deutsch Anlegen von DB-Tabellen (durch Plugins) - Collation?

Hier können Probleme und alles andere in Deutscher Sprache gelöst werden.
thh
Regular
 
Posts: 139
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart

Postby thh » Mon May 15, 2017 10:19 pm

Ich kümmere mich derzeit gerade um ein Update von serendipity_event_dejure, konkret um einen Abgleich der Version 1.2 in Spartacus und der Version 1.5 auf der Webseite von dejure.org (mit Zustimmung der Rechteinhaber, freilich).

Ein wesentlicher Unterschied ist die Anlage einer Cache-Tabelle, insbesondere, was die Collation betrifft. Ich habe mich mal etwas im Code umgeguckt, aber irgendwie macht das jedes Plugin anders ... Daher hier die Frage an die Wissenden: wie macht man's am besten?

Konkret hier die derzeitige Lösung der Version in Spartacus:
Code: Select all
serendipity_db_schema_import("CREATE TABLE {$serendipity['dbPrefix']}dejure (
        ckey varchar(32),
        cache text,
        last_update int(10) {UNSIGNED}
        )");
serendipity_db_schema_import('CREATE UNIQUE INDEX dejure_cacheidx ON {PREFIX}dejure (ckey)');


Und hier die Alternativvariante:
Code: Select all
serendipity_db_schema_import("
    CREATE TABLE {$serendipity['dbPrefix']}dejure (
    `ckey` CHAR( 32 ) NOT NULL COLLATE utf8_unicode_ci,
    `cache` MEDIUMTEXT NOT NULL COLLATE utf8_unicode_ci,
    `last_update` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (
    `ckey`
    )
    ) CHARACTER SET utf8 COLLATE utf8_unicode_ci
");


Was ist besser? Oder machen "wir" das aktuell ganz anders? :)

User avatar
garvinhicking
Core Developer
 
Posts: 29955
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Tue May 16, 2017 10:59 am

Hi!

Potentiell immer eine schwierige Frage; hängt auch etwas ab von meinen beta-Verbeserungen für die 2.2, in der wir utf8mb4 benutzen.

Grundsätzlich ist die erste Variante zu bevorzugen, weil sie auch für SQLite und PostgreSQL funktioniert; die zweite tut das nicht.

Die zweite Variante setzt fest UTF-8 als Collation, was zu inkompatibilitäten führen wird, wenn man KEIN UTF-8 benutzt.

Ich würde daher stark die erste Variante bevorzugen, einzig beim Timestamp weiß ich nicht, ob das im Code dann intern anders ausgewertet wird.
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
onli
Regular
 
Posts: 2055
Joined: Tue Sep 09, 2008 10:04 pm

Postby onli » Tue May 16, 2017 8:08 pm

Generell aber: Eventuell wäre es besser, Cache/Lite zu nutzen? Ein Beispiel dafür ist die serendipity_setupCache() in functions_entries.inc.php. Oder auch im autotitle-Plugin.

thh
Regular
 
Posts: 139
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart

Postby thh » Tue May 16, 2017 8:30 pm

garvinhicking wrote:Potentiell immer eine schwierige Frage; hängt auch etwas ab von meinen beta-Verbeserungen für die 2.2, in der wir utf8mb4 benutzen.


Das hatte ich befürchtet. :)

garvinhicking wrote:Grundsätzlich ist die erste Variante zu bevorzugen, weil sie auch für SQLite und PostgreSQL funktioniert; die zweite tut das nicht.


Was davon würde fehlschlagen? Ginge "NOT NULL"? Oder "MEDIUMTEXT"? Oder "TIMESTAMP" und "DEFAULT CURRENT_TIMESTAMP"?

garvinhicking wrote:Die zweite Variante setzt fest UTF-8 als Collation, was zu inkompatibilitäten führen wird, wenn man KEIN UTF-8 benutzt.


Anderswo im Code habe ich {UTF_8} an dieser Stelle gesehen. Wie wird denn das ersetzt, und: könnte man das verwenden?

garvinhicking wrote:Ich würde daher stark die erste Variante bevorzugen, einzig beim Timestamp weiß ich nicht, ob das im Code dann intern anders ausgewertet wird.


Wenn TIMESTAMP geht ist das m.E. das gegebene; Unterschiede in der Auswertung sollte es nicht geben.

User avatar
garvinhicking
Core Developer
 
Posts: 29955
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany

Postby garvinhicking » Wed May 17, 2017 11:00 am

Hi!

Was davon würde fehlschlagen? Ginge "NOT NULL"? Oder "MEDIUMTEXT"? Oder "TIMESTAMP" und "DEFAULT CURRENT_TIMESTAMP"?


Mediumtext, timestamp UND default current_timestamp :-)

Anderswo im Code habe ich {UTF_8} an dieser Stelle gesehen. Wie wird denn das ersetzt, und: könnte man das verwenden?


Ja, sorry, ganz überlesen. {UTF_8} kann man einfügen, das wird in s9y UTF-MySQL-Installationen dann mit dem Kollationsstring ersetzt.

LG,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

thh
Regular
 
Posts: 139
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart

Postby thh » Fri May 19, 2017 7:21 am

garvinhicking wrote:
Was davon würde fehlschlagen? Ginge "NOT NULL"? Oder "MEDIUMTEXT"? Oder "TIMESTAMP" und "DEFAULT CURRENT_TIMESTAMP"?


Mediumtext, timestamp UND default current_timestamp :-)


SQLite ist eine Freude. :)

thh
Regular
 
Posts: 139
Joined: Thu Oct 26, 2006 2:38 pm
Location: Stuttgart

Postby thh » Fri May 19, 2017 7:30 am

onli wrote:Generell aber: Eventuell wäre es besser, Cache/Lite zu nutzen? Ein Beispiel dafür ist die serendipity_setupCache() in functions_entries.inc.php. Oder auch im autotitle-Plugin.


Ich werde mir das mal notieren für eine potentielle Überarbeitung ...

Der Vernetzungsdienst ist recht simpel gestrickt: man schickt den kompletten Posting-Inhalt hin und bekommt ihn zurück, nachdem Vorschriften und Urteile mit Links "hinterlegt" worden sind. Noch "simpler" ist das Caching, dass in den verschiedenen Beispiel-Plugins in unterschiedlichen Versionen (Datei / DB) gelöst ist: der Dateiname (oder der Key für die Datenbankzeile) ist ein Hash des Originaltextes, der Dateiinhalt (oder eben der Inhalt der Datenbankzeile) ist dann die mit Links hinterlegte Fassung des Textes. Das macht Sinn, da sich wenig ändert; allenfalls kann mal ein Urteil in der Datenbank hinzukommen, und damit ein neuer Link. Man müsste den Cache daher auch nicht nach 4 Tagen invalidieren, wie Upstream das löst; vier Wochen wäre vermutlich auch okay. :)

Das in der Doku verwendete Argument für die Verwendung einer Datenbank ist, dass ein Cache im Filesystem mit vielen Dateien langsam wird. Und potentiell gibt es eben für jeden Blogeintrag eine gecachte Version ...

Anyway, bei mir steht erstmal auf dem Plan, das Plugin auf den aktuellen Stand vom Upstream zu bringen; danach möchte ich die Änderungen übernehmen, die bspw. für Wordpress schon eingearbeitet sind, aber in unser s9y-Plugin noch nicht. Und dann schauen wir mal. :)

PS: Ich habe Dein Plugin nicht vergessen, aber leider noch nicht die Muße gehabt, reinzuschauen. Ich versuche es am Wochenende, sonst am Wochenende drauf - ist leider gerade etwas stressig hier.



Return to Generelles in Deutsch

Who is online

Users browsing this forum: No registered users and 7 guests