Problem mit SQLite und timestamp-Werten, die nil und doch nicht nil sind

Community DE
#1

Hallo, ich würde mich freuen, zu hören, ob jemand von Euch folgendes
Problem
schon mal gehabt hat:

Ich habe eine (bestehende) SQLite3 Datenbank, die ich in Rails anzapfen
möchte.

In meinem Model habe ich folgende Methode, die mir Datensätze
zurückgibt:

def self.open_tasks
find(:all, :conditions => ‘ZDONE=0 AND ZSTARTDATE < ‘now’ AND
ZTAGS
NOTNULL AND ZDUEDATE NOTNULL’, :order => ‘ZDUEDATE ASC’)
end

Wenn ich mir das Ergbnis mit to_yaml ausgeben lasse, ist ZDUEDATE
gesetzt -
to_yaml gibt so was aus:

  • !ruby/object:Task
    attributes:
    …
    ZDUEDATE: “217162800”
    …

Auf die Abfrage if nil == ZDUEDATE erhalte ich immer, dass ZDUEDATE nil
ist

  • was ja laut to_yaml und nach meiner Query (ZDUEDATE NOTNULL) nicht
    stimmt.
    Bsp:
    def due_date
    nil != self.ZDUEDATE ? self.ZDUEDATE.strftime("%d.%m.%g") : “–not
    set–”
    end
    gibt immer “–not set–”

Für mich gibt es zwei Erklärungsmöglichkeiten:

  • Das Problem tritt auf, weil der Spaltenname nur aus Großbuchstaben
    besteht
    (“ZDUEDATE”). Hat da jemand einen Ansatz?
  • Rails kann den Typ TIMESTAMP von SQLite nicht verarbeiten. Das wäre
    denkbar, weil von Rails generierte Datenbanken den Typ datetime
    verwenden.
    Hat jemand Erfahrung mit der Konvertierung von timestamp in datetime?
  • sonst: Ratlos

Insofern würde ich mich sehr über Vorschläge oder Erklärungen freuen!

Gibt es eigentlich eine Möglichkeit, die Spaltennamen umzubenennen, so
dass
ich nicht ZDUEDATE schreiben muss? So was wie set_table_name, nur für
Spalten?

Hier ist noch mal das Schema der Tabelle:

sqlite> .schema ZTASK
CREATE TABLE ZTASK ( Z_ENT INTEGER, Z_PK INTEGER PRIMARY KEY, Z_OPT
INTEGER,
ZEFFORT INTEGER, ZNEWINPROJECT INTEGER, ZRECURTYPE INTEGER, ZURL
VARCHAR,
ZDELEGATED INTEGER, ZPOSITIONINCONTEXT INTEGER, ZCLEANEDUP INTEGER,
ZNAME
VARCHAR, ZDONE INTEGER, ZNEWINCONTEXT INTEGER, ZCONTENT VARCHAR,
ZDUEDATE
TIMESTAMP, ZNEXTACTION INTEGER, ZCOMPLETIONDATE TIMESTAMP, ZMAYBE
INTEGER,
ZRECURMODE INTEGER, ZRECURNUMBER INTEGER, ZSTARTDATE TIMESTAMP,
ZPRIORITY
INTEGER, ZARCHIVED INTEGER, ZSYNCID VARCHAR, ZCONTACT VARCHAR,
ZPOSITIONINPROJECT INTEGER, ZWAITINGFOR INTEGER, ZTAGS VARCHAR,
ZPARENTPROJECT INTEGER, ZPARENTARCHIVECATEGORY INTEGER, ZPARENTCONTEXT
INTEGER );

sqlite> select sqlite_version();
3.1.3

Das ist übrigends eine Tabelle von iGTD, dem “Getting Things Done”-Tool
für
Mac, falls jemand direkt in die DB schauen möchte, das dürften ja einige
nutzen :slight_smile:

Besten Dank,

Björn

#2

Was ich in der Zwischenzeit festgestellt habe, ist, dass ich mit

SELECT datetime(ZDUEDATE + (8 + 365 * 31) * 24 *60 *60,
‘unixepoch’,‘localtime’) from ZTASK

ein richtiges Datum im Textformat kriege. Sprich, man muss 31 Jahre
hinzuaddieren.
Das liegt daran, dass iGTD mit der Zählung im Jahr 2001 anfängt, statt
1970.

Es bleibt die Frage: Wie kann ich auf den Wert von ZDUEDATE in Rails
zugreifen, wenn mein_objekt.ZDUEDATE nil zurückgibt, während
mein_objekt.to_yaml für ZDUEDATE einen Wert enthält?
Wieso das? Weiß jemand, wo Rails mit dem timestamp Typ von SQLite ein
Problem hat?

Wie kann man vorgehen, um die übliche find-Methode verwenden zu können
und
statt dem Feld mit ZDUEDATE als timestamp-Typ ein datetime zu kriegen,
mit
dem man in Rails arbeiten kann? Hat da jemand eine ausgefuchste Idee?
Ich möchte ja gerne active_record nutzen :slight_smile:

Ich würde mich sehr über Antworten freuen.

Schöne Grüße,
Björn