Ruby Forum Rails Germany > Problem mit SQLite und timestamp-Werten, die nil und doch nicht nil sind

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 :-)


Besten Dank,

Björn

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 :-)

Ich würde mich sehr über Antworten freuen.

Schöne Grüße,
Björn