Datum 2021-11-.... wird nach Join zu timestamp

egerlach

Benutzer
Beiträge
9
Hallo,

ein mySQL-Datenfeld "created_at" wird nach einem Join ungewollt zum timestamp:

In der Tabelle z.B. 2021-04-10 22:17:15 wird dann zu 1636126829
nach dem Join. Der Join, beachte darin: actions.created_at, darum gehts:

SELECT contacts.id, email, contacts.first_name, contacts.last_name, links.id, links.link, actions.created_at, actions.count FROM n4chl_ig_contacts AS contacts
LEFT JOIN n4chl_ig_actions AS actions ON contacts.id = actions.contact_id LEFT JOIN n4chl_ig_links AS links ON links.id = actions.link_id
WHERE actions.`campaign_id` between 53 and 87 AND actions.`type` = 4

warum? wie kann ich das verhindern? - Wenn ich from_unixtime(actions.created_at) mache, kommt immer nur "Null" heraus.
Es ist eine mySQL-DB für meine Webseite bei meinem Provider all-ink.com, es ist eine tabelle von wordpress. Bin mit phpmyadmin drauf. Wenn ich die Tabelle exportiere und herunterlade, steht bei created_at tatsächlich das Datum in der form 2021-11-.... drinnen, NICHT ein timestamp.
danke schonmal
Eckard
 
Zuletzt bearbeitet:
Werbung:
Tjy, MySQL und seine Bugs mal wieder, gell?

Übrigens ist das Datum um Monate falsch:

Code:
edb=*# SELECT TIMESTAMP WITH TIME ZONE 'epoch' +  1636126829 * INTERVAL '1 second';
        ?column?       
------------------------
 2021-11-05 16:40:29+01
(1 row)

edb=*#

Und nicht 2021-04-10 22:17:15, oder anders rum:

Code:
edb=*# SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2021-04-10 22:17:15');
 date_part  
------------
 1618085835
(1 row)

Immerhin hat sich MySQL um schlappe 18040994 Sekunden verrechnet. Toll , oder?
 
ein mySQL-Datenfeld "created_at" wird nach einem Join ungewollt zum timestamp:

In der Tabelle z.B. 2021-04-10 22:17:15 wird dann zu 1636126829

Im übrigen: '2021-04-10 22:17:15' ist ein TIMESTAMP, während 1636126829 in INTEGER ist. Verwirrend, oder?

Code:
edb=*# select pg_typeof('2021-04-10 22:17:15'::timestamp);
          pg_typeof         
-----------------------------
 timestamp without time zone
(1 row)

edb=*# select pg_typeof(1636126829);
 pg_typeof
-----------
 integer
(1 row)

edb=*#

(der CAST zu TIMESTAMP im ersten Beispiel in der Klammer ist nötig, weil es auch ein STRING-Datentyp sein könnte)
 
Danke fürs Nachrechnen, der integer war nur ein Beispiel, die Tabelle so riesig, ich wollte nicht noch den richtigen record suchen.

Hast Du für mich auch eine Lösng für mein Problem parat, warum die Anzeige von created_at von TIMESTAMP auf integer (Unix timestamp integer) gewandelt wird?
Wie verhindere ich das? Das stört mich sehr beim lesen/arbeiten, ich muss Daten aus diesem Join in ein anderes System übertragen und da wäre ein lesbares Datum sehr hilfreich.

Gruß
Eckard
 
Hast Du für mich auch eine Lösng für mein Problem parat, warum die Anzeige von created_at von TIMESTAMP auf integer (Unix timestamp integer) gewandelt wird?
Wie verhindere ich das? Das stört mich sehr beim lesen/arbeiten, ich muss Daten aus diesem Join in ein anderes System übertragen und da wäre ein lesbares Datum sehr hilfreich.

Verständlich, dazu dienen solche Datentypen ja auch (u.a.).

Daß MySQL vieles nicht kann und das wenige, was es vorgibt zu können dann oft falsch macht, macht es einfach zu einer schlechten Wahl als Datenbank. Man will ja der Datenbank vertrauen, daß gespeicherte Daten nicht verloren gehen oder verändert werden.
Darum auch verwenden z.B. unsere Kunden (dazu zählen viele weltweit bekannte Firmen, z.B. weltweit in der Finazbranche agierende, Pharmafirmen, Auohersteller, Energieerzeuger, ...) halt kein MySQL.

In diesem Sinne kann ich Dir eigentlich nur den Umstieg empfehlen, als langfristig sichere Lösung.
 
Ich setze auf raspis meiner Kunden mariaDB ein. Allerdings sehr einfache Datenbank, 2 Tabellen. Läuft aber 1,5 Jahre schon ohne ausfall.
Leider kann ich meinen Provider all-inkl.com sicherlich nicht dazu bewegen, von mySQL auf z.B. postgreSQL umzusteigen, es ist leider der Standard, wie auch M$ auf Desktops, ich habe ubuntu.
Also ist die Anzeige als integer timestamp ein Fehler, ok. Wie behebe ich diesen Fehler?
 
schick doch mal die creates der tabellen und 2 - 3 zeilen testdaten.

welche MariaDB version setzt du ein ?

Gruß

Bernd

P.S. Maria ist schon die richtige Wahl !
 
schick doch mal die creates der tabellen und 2 - 3 zeilen testdaten.

welche MariaDB version setzt du ein ?

Gruß

Bernd

P.S. Maria ist schon die richtige Wahl !

Die Maria von debian 10.3 . Die Maria hat aber nichts mit dem MySQL von meinem Webseiten-Provider zu tun.
Danke Dir für das Angebot, dass Du die Tabellen einliest und dann mal schaust... , für mich ist es aber ein zu großer Aufwand die Email-Adressen darin zu anonymisieren, es ist eine eMail-Marketing -Datenbank. Außerdem müßte ich dann noch Paare zusammenzusuchen die für einen Join passen, damit was Sicherbares herauskommt, zuviel Aufwand. Mit dem "timestamp - integer" kann ich auch leben. Ich hatte gehofft,. dass es ein bekanntes feature wäre für das es schon fertige Lösungen gibt. Wenn hier jetzt keine Lösung kommt, lebe ich einfach damit.
Gruß
Eckard
 
Kein Problem!. Du könntest aber die leeren Tabellen (creates) schicken ohne sensible Daten zu veröffentlichen.
Ich kann diesen Fehler noch nicht glauben, würde dann aber einen Fehler einstellen wenn ich den nachstellen kann.

Gruß

Bernd
 
ahh ... ok .. das mache ich ...

Oha!!! all-inkl.com ist auf mariaDB umgestiegen!!! Gar nicht bemerkt, im header jedes export steht drinnen:

-- Server-Version: 10.5.11-MariaDB-1:10.5.11+maria~focal-log

Der bug ist somit ein mariaDB-Bug.

Ja, der sollte behoben werden in einer nächsten Version! Auf jeden Fall!!
 
Zuletzt bearbeitet:
Hier der download der 3 Tabellen: http://aiai.de/foren/bug-timestamp-mariaDB.tar.gz

Hier nochmal der join:
SELECT contacts.id, email, contacts.first_name, contacts.last_name, links.id, links.link, actions.created_at, actions.count FROM n4chl_ig_contacts AS contacts
LEFT JOIN n4chl_ig_actions AS actions ON contacts.id = actions.contact_id LEFT JOIN n4chl_ig_links AS links ON links.id = actions.link_id
WHERE actions.`campaign_id` between 53 and 87 AND actions.`type` = 4
 
Zuletzt bearbeitet:
Tja, hab mir jetzt nicht alles im Forum durchgelesen. Aber ich kann den FEHLER erzeugen.

Der fällt in die Kategorie: Shit in -> Shit out :)

Schau dir mal dein CREATE an für die Tabelle n4chl_ig_actions mit dem alias action:

Code:
CREATE TABLE `n4chl_ig_actions` (
  `contact_id` bigint(20) unsigned DEFAULT NULL,
...
...
...
 `created_at` int(11) unsigned NOT NULL DEFAULT 0,
  `updated_at` int(11) unsigned NOT NULL DEFAULT 0,
  UNIQUE KEY `id` (`contact_id`,`message_id`,`campaign_id`,`type`,`link_id`,`list_id`),
  KEY `contact_id` (`contact_id`),
  KEY `message_id` (`message_id`),
  KEY `campaign_id` (`campaign_id`),
  KEY `type` (`type`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;

Das Feld created_at ist vom Type INT !! Warum sollte MySQL da ein Date draus machen.

P.S. Du solltest dich auch von der Engine MyISAM langsam verabschieden, falls diese nicht zwingend notwendig ist und
dafür InnoDB einsetzen. MyISAM macht bei jedem WRITE ein FULL TABLE LOCK

Gruß

Bernd
 
Interessant ... und warum zeigt die Tabelle dann phpMyAdmin einen timestamp (z.B. 2021-11-06.......) an und nach dem Join einen integer-timestamp? - Ich kann das mal an den Hersteller des wordpress-plugin weitergeben, die haben das gemacht.
Was wäre der richtige typ? "date"? Gibts den?
Zur Engine: hat der Hersteller der Software darauf einen Einfluss? Ist das nicht Provider-Sache, hier all-inkl.com?
 
Nur mal kurz. In KEINER deiner Tabellen ist ein Timestamp drin. In der Tabelle n4chl_ig_links ist created_at als DATETIME definiert.

Na klar gibt der Hersteller die Engine vor und MyISAM ist halt noch aus grauer Vorzeit drin. Wurde zwar verbessert, hat aber noch jede Menge Nachteile.

Ach und versuch es mal mit einem vernünftigen SQL Client oder der CLI von MySQL
 
Werbung:
Danke für die Info. Das mit myISAM hat der Hersteller der plugin vermutlich aus Gründen der Kompatibilität mit Providern weltweit gemacht, viele haben sicherlich noch mySQL und können noch nicht innoDB. Aber ich schreibe ihm das mal und weise darauf hin, dass Datum-Felder wie created_at mal als unsigned und mal als datetime definiert sind. Vermutlich alles historisch gewachsen, das alles zu bereinigen ist vermutlich nicht so einfach.
 
Zurück
Oben