You can clone with
HTTPS or Subversion.
Data given to the model:
'content' => string 'test' (length=4)
'user_id' => string 'UCR76EQO' (length=8)
'timestamp' => string '2013-01-07 13:57:03.621684' (length=26)
Resulting query of $model->save():
INSERT INTO "sq_message" ("timestamp", "content", "user_id") VALUES ('2013-01-07 13:54:48', 'test', 'UCR76EQO');
As you can see the micro seconds are not in the query and thus not saved! Im using postgres as database.
The field in the database is defined as:
"timestamp" timestamp without time zone NOT NULL DEFAULT now()
A unix timestamp only goes as far as seconds, you should use a different field if you need milliseconds.
It is a postgres timestamp and I am using the correct format for that.
I dont use unix timestamps anywhere...
OK thanks for clarifying that!
I do think that this had something to do with the unix timestamp. Maybe lithium converts it somwhere. Or maybe it uses the php DateTime class (that doesn't work properly with microseconds!)
But I didn't go into it deep enough the verifiy that.
Because of the wide variety of date format over databases, I'm fine with the fact that the ORM use the lowest common denominator for managing the 'datetime' type (I mean the framework 'datetime' type here). Moreover this allow to switch over RDBMS with relative serenity.
The crappy workaround would be to: set your own $_schema in the model and using 'string' instead of 'datetime' for the concerned field to not be "annoyed" by the default behavior.
Or you can also extends/PR the core PostgreSql database adatper and add a new entry in PostgreSq::_columns, with an arbitrary name, not depending on the 'formatter' => 'date' since it currenlty based on strtotime (or change this behavior). Don't forget here to also change the PostgreSq::_column() to make it detect timestamp(p) as your new created entry.
'formatter' => 'date'
Unfortunately this is not a small annoyance to me since I have to log certain events and the order of those events is very important. While testing there where a lot of cases where the events occurred in the same second thus ruining the order!
I implemented your "crappy" workaround with success! Thanks.
However the microseconds are in the sql standard for datetime and there is currently no RDBMS supported in lithium that would break, Sqllite does not have a timestamp field (their datetime functions do support it) and MySql simply ignores the microseconds.
But there are probably more important things to take care of right now so consider it a feature request then.
Thanks for the feedback on this !
Easier custom data types are coming in the future. Hang tight. :-)
I think that #855 is related and could solve this issue for the OP. Please review.
Closed in flavor of #858.