Roger Andersson wrote:
> On 02/11/12 15:22, Kit wrote:
>> 2012/2/10 Willian Gustavo
>> Veiga<[email protected]>:
>>> SQLite is a great database to unit test (TDD) applications. You can
>>> run it
>>> in memory with your tests ...
>>>
>>> I've found a problem when I was unit testing my application. MySQL
>>> (production database) supports EXTRACT SQL standard function. SQLite
>>> don't
>>> support it. It would be great to have support in this standard.
>>> Unfortunately, strftime isn't a solution. It's not a standard.
>> Function strftime is your solution. Write two models. One for MySQL,
>> one for SQLite. These databases are quite different and require
>> different SQL queries.
> Maybe views could be used to handle differences, at least some of them ;-)
> sqlite> create view dateCurrent as
> ...> select
> ...> substr(date(),0,5) as year,
> ...> substr(date(),6,2) as month,
> ...> substr(date(),9,2) as day;
> sqlite> .header on
> sqlite> select * from dateCurrent;
> year|month|day
> 2012|02|12
>
> mysql> create view dateCurrent as
> -> select
> -> substr(current_date,1,4) as year,
> -> substr(current_date,6,2) as month,
> -> substr(current_date,9,2) as day;
> mysql> select * from dateCurrent;
> +------+-------+-----+
> | year | month | day |
> +------+-------+-----+
> | 2012 | 02 | 12 |
> +------+-------+-----+
I wonder, how it will be handled if you issue such request at month/year/...
change (23:59.59.999 GMT -> 00:00:00.000 GMT)?
Is timestamp for current_date/current_time generated once and cached at start of
SELECT evaluation?
It is certainly *not* cached for different rows:
SELECT *, current_date, current_time, current_time FROM t
while($row = $sth -> fetch) { print ++$i," row: @$row"; sleep 5; }
1 row: 0 2012-02-12 19:20:40 19:20:40
2 row: 1 2012-02-12 19:20:40 19:20:40
3 row: 2 2012-02-12 19:20:45 19:20:45
4 row: 3 2012-02-12 19:20:50 19:20:50
5 row: 4 2012-02-12 19:20:55 19:20:55
(two first are same due to sqlite [or perl DBI binding?] seems executes one row
ahead).
But do they use same cached value *within one row*?
If not, results may be randomly inconsistent and broken (race condition).
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
