<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>

CC BY-SA 3.0
2014-09-26T18:04:43.523Z
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.
Lindsey D
CC BY-SA 3.0
2014-09-26T18:06:36.243Z
Not explicitly, no. Joins may or may not be created as a by-product of the parameters set on the model, though.
Brad Bell
CC BY-SA 3.0
2014-09-26T18:11:56.650Z
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?
Lindsey D
CC BY-SA 3.0
2014-09-26T18:13:46.903Z
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?
Lindsey D
CC BY-SA 3.0
2014-09-26T18:21:03.763Z
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.
Brad Bell
CC BY-SA 3.0
2014-09-26T18:43:55.037Z
@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.
Fred Carlsen
CC BY-SA 3.0
2014-09-26T18:46:16.703Z
@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.
Brad Bell
CC BY-SA 3.0
2014-09-26T18:46:47.117Z
@FredCarlsen Yeah, would probably fall in with the custom element type documentation that needs to be written.
Brad Bell
CC BY-SA 3.0
2014-09-27T20:59:16.953Z
@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)
Lindsey D
CC BY-SA 3.0
2014-09-26T17:59:18.340Z
2014-09-26T17:59:18.340Z
Brad Bell
<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>

CC BY-SA 3.0
2014-09-26T16:41:28.353Z
Thanks David, that's certainly one aspect of it. I feel like there are probably some other nuances to be aware of as well.
Lindsey D
CC BY-SA 3.0
2014-09-26T16:44:39.237Z
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!
Lindsey D
CC BY-SA 3.0
2014-09-26T08:02:13.653Z
2014-09-26T08:02:13.653Z
David A McInnis
<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>

<plugin-development><elementcriteriamodel><queries>
What's the difference between ElementCriteriaModel and DbCommand?
# 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 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.  
> **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**: @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.  
> **username_1**: @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.  
> **username_1**: @FredCarlsen Yeah, would probably fall in with the custom element type documentation that needs to be written.  
> **username_0**: @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)  

---

### 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 David, 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!  

---

