Answers.Body: <p><a href="http://buildwithcraft.com/classreference/etc/db/DbCommand" rel="nofollow">DbCommand</a> represents a SQL statement to execute against a database.</p>
  
  <p><a href="http://buildwithcraft.com/classreference/models/ElementCriteriaModel" rel="nofollow">ElementCriteriaModel</a> is a model just like any other model in <code>craft/app/models</code>, but it also happens to make it easy to search for <a href="http://buildwithcraft.com/classreference/#craft.app.elementtypes" rel="nofollow">Elements</a> in the database.</p>
  
  <p>By setting all of the criteria for the elements you're searching for and calling the <a href="http://buildwithcraft.com/classreference/models/ElementCriteriaModel#find-detail" rel="nofollow">find()</a> method, that will invoke <code>craft()-&gt;elements-&gt;findElements($this);</code>, which in turn will create a DbCommand object custom built for the ElementCriterialModel parameters that you set.</p>
  
  <p>So think of ElementCriteriaModel as an abstraction on top of DbCommand that makes it easy to search for Elements.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:04:43.523Z
Answers.Text: Thanks Brad, great explanation! Is there any way via ElementCriteriaModel to perform a `join` with another table? The abstraction is great, but it seems to come with a few limitations.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:06:36.243Z
Answers.Text: Not explicitly, no. Joins may or may not be created as a by-product of the parameters set on the model, though.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:11:56.650Z
Answers.Text: You're saying that the ElementCriteriaModel could very likely create some inherent joins in its standard operations. Is there a reasonable way to tack on an additional join after it's been parsed into a DbCommand? Or would it be better to directly run a DbCommand if I want to do something crazy like that?
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:13:46.903Z
Answers.Text: On a similar note, is it possible to "intercept" the DbCommand that gets generated, between the time that it's generated and the time that it's executed?
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:21:03.763Z
Answers.Text: Yeah, I think you're better off using DbCommand to craft (get it?) the exact query you need. Re: intercepting, possible, depending on if you want it before it's been parsed down to SQL. But you'd be extending DbCommand with your own logic to override.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:43:55.037Z
Answers.Text: @BradBell On a related note, would it be a good idea in the future to have some official example of how to do what Lindsey mentions, if at all possible? For example, have Craft do most of it's magic, but then join in some custom data from a join or something. I already have several contexts where I simply just wanted to tack on some attributes on an existing model.
Answers.UserDisplayName: Fred Carlsen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:46:16.703Z
Answers.Text: @LindseyD Worth mentioning that if you're in the context of a custom element type, then you've got the modifyElementsQuery() method that you can override to do your own query modifications.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T18:46:47.117Z
Answers.Text: @FredCarlsen Yeah, would probably fall in with the custom element type documentation that needs to be written.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-27T20:59:16.953Z
Answers.Text: @FredCarlsen Just discovered `buildElementsQuery`, which works perfectly in this case! [I posted a separate SE question/answer to show how it works...](http://craftcms.stackexchange.com/q/2786/45)
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T17:59:18.340Z
Answers.LastActivityDate: 2014-09-26T17:59:18.340Z
Answers.UserDisplayName: Brad Bell
Answers.Body: <p>I assume that one advantage would be that as Craft gets updated, the ElementCriteriaModel is updated whereas you may need to change any DBCommand queries you have created.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T16:41:28.353Z
Answers.Text: Thanks David, that's certainly one aspect of it. I feel like there are probably some other nuances to be aware of as well.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T16:44:39.237Z
Answers.Text: You do touch on a great point... P&T reserves the right to change their database schema at any time, in any way. If you're conducting your queries entirely via ElementCriteriaModel, then you wouldn't have to worry about any schema changes. On the other hand, any DBCommands may have to be completely rewritten. Thanks!
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-26T08:02:13.653Z
Answers.LastActivityDate: 2014-09-26T08:02:13.653Z
Answers.UserDisplayName: David A McInnis
Body: <p>Forgive me if this is a stupid or naive question...</p>
  
  <p>I generally think of an <strong>ElementCriteriaModel</strong> as being a "search object". Specifically, it's a search object which revolves around a specific type of element. The model has attributes like <code>order</code>, <code>offset</code> and <code>limit</code>, which are obviously common terms when conducting an SQL query.</p>
  
  <p>On the other hand, a <strong>DbCommand</strong> is an object which directly translates to an SQL query. This is far more flexible, allowing you to do things like perform complex joins.</p>
  
  <p>So while I can certainly see <em>some</em> differences, it's hard for me to grasp the finer points of one vs. the other. (I'll admit that typing this has helped me to see it a little more clearly.)</p>
  
  <p>What am I missing/misunderstanding?</p>
  
Tags: <plugin-development><elementcriteriamodel><queries>
Title: What's the difference between ElementCriteriaModel and DbCommand?
ThreadText: # What's the difference between ElementCriteriaModel and DbCommand?
  
  (Asked by: username_0 on 2014-09-26)
  
  Forgive me if this is a stupid or naive question...
  
  I generally think of an **ElementCriteriaModel** as being a "search object". Specifically, it's a search object which revolves around a specific type of element. The model has attributes like `order`, `offset` and `limit`, which are obviously common terms when conducting an SQL query.
  
  On the other hand, a **DbCommand** is an object which directly translates to an SQL query. This is far more flexible, allowing you to do things like perform complex joins.
  
  So while I can certainly see *some* differences, it's hard for me to grasp the finer points of one vs. the other. (I'll admit that typing this has helped me to see it a little more clearly.)
  
  What am I missing/misunderstanding?
  
  **Tags:** plugin-development, elementcriteriamodel, queries
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2014-09-26. Score: 3 | Accepted answer
  
  [DbCommand](http://buildwithcraft.com/classreference/etc/db/DbCommand) represents a SQL statement to execute against a database.
  
  [ElementCriteriaModel](http://buildwithcraft.com/classreference/models/ElementCriteriaModel) is a model just like any other model in `craft/app/models`, but it also happens to make it easy to search for [Elements](http://buildwithcraft.com/classreference/#craft.app.elementtypes) in the database.
  
  By setting all of the criteria for the elements you're searching for and calling the [find()](http://buildwithcraft.com/classreference/models/ElementCriteriaModel#find-detail) method, that will invoke `craft()->elements->findElements($this);`, which in turn will create a DbCommand object custom built for the ElementCriterialModel parameters that you set.
  
  So think of ElementCriteriaModel as an abstraction on top of DbCommand that makes it easy to search for Elements.
  
  > **Comments:**
  > **username_0**: Thanks username_1, great explanation! Is there any way via ElementCriteriaModel to perform a `join` with another table? The abstraction is great, but it seems to come with a few limitations.  
  > **username_1**: Not explicitly, no. Joins may or may not be created as a by-product of the parameters set on the model, though.  
  > **username_0**: You're saying that the ElementCriteriaModel could very likely create some inherent joins in its standard operations. Is there a reasonable way to tack on an additional join after it's been parsed into a DbCommand? Or would it be better to directly run a DbCommand if I want to do something crazy like that?  
  > **username_0**: On a similar note, is it possible to "intercept" the DbCommand that gets generated, between the time that it's generated and the time that it's executed?  
  > **username_1**: Yeah, I think you're better off using DbCommand to craft (get it?) the exact query you need. Re: intercepting, possible, depending on if you want it before it's been parsed down to SQL. But you'd be extending DbCommand with your own logic to override.  
  > **username_2**: @username_1 On a related note, would it be a good idea in the future to have some official example of how to do what username_0 mentions, if at all possible? For example, have Craft do most of it's magic, but then join in some custom data from a join or something. I already have several contexts where I simply just wanted to tack on some attributes on an existing model.  
  > **username_1**: @username_0 Worth mentioning that if you're in the context of a custom element type, then you've got the modifyElementsQuery() method that you can override to do your own query modifications.  
  > **username_1**: @username_2 Yeah, would probably fall in with the custom element type documentation that needs to be written.  
  > **username_0**: @username_2 Just discovered `buildElementsQuery`, which works perfectly in this case! [I posted a separate SE question/answer to show how it works...](http://craftcms.stackexchange.com/q/2786/45)  
  
  ---
  
  ### Answer by username_3 on 2014-09-26. Score: 1
  
  I assume that one advantage would be that as Craft gets updated, the ElementCriteriaModel is updated whereas you may need to change any DBCommand queries you have created.
  
  > **Comments:**
  > **username_0**: Thanks username_3, that's certainly one aspect of it. I feel like there are probably some other nuances to be aware of as well.  
  > **username_0**: You do touch on a great point... P&T reserves the right to change their database schema at any time, in any way. If you're conducting your queries entirely via ElementCriteriaModel, then you wouldn't have to worry about any schema changes. On the other hand, any DBCommands may have to be completely rewritten. Thanks!  
  
  ---
  
  