Yes, but it is one level above native date/time fields. All databases have equivalent functions for date math and the like (EXTRACT, INTERVAL, ...etc). My point was the need for in-SQL operations for queries, which no matter how you abstract the individual CRUD (we already have user_load() and node_load() for that), you still need in-SQL for reporting and aggreggation. On Dec 3, 2007 7:40 PM, Larry Garfield <larry@garfieldtech.com> wrote:
On Mon, 3 Dec 2007 18:42:56 -0500, "Khalid Baheyeldin" <kb@2bits.com> wrote:
On Dec 3, 2007 1:49 AM, Larry Garfield <larry@garfieldtech.com> wrote:
As for in-SQL operations on the date value, like MONTH() or YEAR() in MySQL? If someone has an idea for those that doesn't involve regexing every
query
I would dearly love to hear it. :-)
The current use of UNIX timestamp is a compromise, and has its issues, but still allows in-SQL operations.
In-SQL operations is very very important. Going to ActiveRecord type of abstraction without the ability to do aggregate operations on the data is just not an option.
Without in-SQL, doing things like:
select n.nid, n.type, n.title, count(*) as num_votes, avg(value) as avg_vote from votingapi_vote v inner join node n on content_id = n.nid where n.type = 'image' and n.created between unix_timestamp('2007-11-01 00:00:00') and unix_timestamp('2007-11-30 23:59:59') group by v.content_id having num_votes
1 order by avg_vote desc, num_votes desc limit 20;
Would be impossible, or would entail very expensive full table scans.
Except that unix_timestamp() is MySQL-specific, isn't it?
--Larry Garfield
-- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.