Monthly Archives has been updated. It has been tested with SQLite, but not MySQL or Postgres. It should no longer be broken. If it is, please reopen the ticket for it. Also note that no php was required in the query.
As a side note, functions like MONTH, YEAR, UNIX_TIMESTAMP (which is all that is needed to get the query to work), NOW, etc are *not* portable to all database platforms. The minute you get beyond the very basics, translations have to be made. Rick On Sep 17, 2:50 am, Andy C <[EMAIL PROTECTED]> wrote: > I am not a Habari or PHP developer. Surprisingly, I don't stay up all > night monitoring svn commits. Indeed I am not qualified to do so. > > I just thought the design merited some discussion and I am glad I > aired the topic. > > For the record, I would have favoured a UTC timestamp with a wrapper > function to adjust for the local timezone. > > Unsigned integers work. The functionality works (and more). It doesn't > matter to the end user or most developers. It ain't worth reverting. > > There are some arguments for unsigned integers and it is clear a vote > would have confirmed the current decision. > > This snippet from the wonderful (and now broken) monthly archives > plugin illustrates the point beautifully > > $q= 'SELECT YEAR( p.pubdate ) AS year, MONTH( p.pubdate ) AS month, > COUNT( p.id ) AS cnt > FROM ' . DB::table( 'posts' ) . ' p > WHERE p.content_type = ? AND p.status = ? > GROUP BY year, month > ORDER BY p.pubdate DESC ' . $limit > > Self-documenting, captures all the semantics in five lines, portable > to all database platforms. > > Now, obviously, this can be fixed by coding the equivalent in PHP - > it's only 1's and 0's after all but I doubt the solution would be as > concise and elegant. > > Oh and please don't tell me integers are better for performance. I > work for Oracle. Databases are here to stay :-) > > Habari - the next generation blogging platform (at least until 2038) --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
