anewt-developers team mailing list archive

[Wouter Bolsterlee <uws@xxxxxxxxx>]

2009-07-22 klockan 09:57 skrev Sander van Schouwenburg:
> Wouter Bolsterlee wrote:
>> I think my recent feature addition to AnewtAutoRecord covers most of the
>> JOIN use cases I can think of without adding too much black magic to
>> AnewtAutoRecord that renders the whole thing into a black box full of
>> spaghetti code paths. [...]

> Yeah, you're probably right. I can't think of a case right now where a  
> join descriptor really adds much to your proposal. My main point is a  
> common join I want to do in pretty much all queries on that table, but  
> you could probably make a method which returns the default join code.

I can see why that would be useful in some cases, but JOINs are expensive
database operations you want to avoid if possible, especially when you have
multi-million row tables (I have some experience with this in the past where
this was really an issue). My personal opinion is that AnewtAutoRecord is
designed to be a thin convenience wrapper, and not a complete ORM solution,
so I'd like to keep it lean and mean. Transparent JOINs are not part of that
design philosophy, I think.

Coming back to your use case... let's use a news item/comments relation as
an example. I suspect one will only use one or two entry points to obtain
records, so you can just write a custom finder method like
db_find_latest_new_items() or something like that. The implementation of
such a method would be quite straight-forward:

  function db_find_latest_new_items()
  {
    return NewsItem::db_find_all_by_sql(array(
      'order-by' => '`date` DESC'
      'limit' => '10',
      'table-alias' => 'n_i',
      'select' => 'COUNT(`comments`) AS `n_comments`',
      'join' => 'LEFT JOIN `news_comments` n_c ON (n_c.`news_item_id` = n_i.`id`)',
    ));
  }

As always, my examples are untested. ;)

    — Wouter

Attachment: signature.asc
Description: Digital signature