Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Updates are handled identically to inserts when using the save
method. The only difference is that instead of starting with a new entity, we start with an existing entity.
You can update multiple fields at once using the update
method. This is similar to the create
method for creating new entities.
There is no need to call save
when using the update
method.
Updates can be performed against any number of entities that match a given query.
New Quick entities can be created and persisted to the database by creating a new entity instance, setting the attributes on the entity, and then calling the save
method.
When we call save
, the record is persisted from the database and the primary key is set to the auto-generated value (if any).
Another option is to use the create
method. This method accepts a struct of data and creates a new instance with the data specified.
You can delete an entity by calling the delete
method on it.
Note: The entity will still exist in any variables you have stored it in, even though it has been deleted from the database.
Just like updateAll
, you can delete many records from the database by specifying a query with constraints and then calling the deleteAll
method.
Additionally, you can pass in an array of ids to deleteAll
to delete only those ids.
You can do this any way you'd like: through the web admin, in Application.cfc
, or using cfconfig.
Make sure to set this.datasource
in your Application.cfc
so Quick knows which datasource to use.
quick
in your Application.cfc
For a default installation in a ColdBox template, the following line will do the trick.
this.mappings[ "/quick" ] = COLDBOX_APP_ROOT_PATH & "/modules/quick";
defaultGrammar
in config/ColdBox.cfc
Quick will auto discover your grammar by default on startup. To avoid this check, set a BaseGrammar
.
BaseGrammar
is a module setting for Quick. Set it in your config/ColdBox.cfc
like so:
Valid options are any of the qb supported grammars. At the time of writing valid grammar options are: MySQLGrammar, PostgresGrammar, MSSQLGrammar and OracleGrammar. Please check the qb docs for additional options.
If you want to use a different datasource and/or grammar for individual entitities you can do so by adding some metadata attributes to your entities.
Once you have an entity and its associated database table you can start retrieving data from your database.
You start every interaction with Quick with an instance of an entity. The easiest way to do this is using WireBox. getInstance
is available in all handlers by default. WireBox can easily be injected in to any other class you need using inject="wirebox"
.
Quick is backed by qb, a CFML Query Builder. With this in mind, think of retrieving records for your entities like interacting with qb. For example:
In addition to using for
you can utilize the each
function on arrays. For example:
You can add constraints to the query just the same as you would using qb directly:
For more information on what is possible with qb, check out the qb documentation.
A second way to retrieve results is to use a Quick Service. It is similar to a VirtualEntityService
from cborm.
The easiest way to create a Quick Service is to inject it using the quickService:
dsl:
Any method you can call on an entity can be called on the service:
Calling qb's aggregate methods (count
, max
, etc.) will return the appropriate value instead of an entity or collection of entities.
There are a few custom retrieval methods for Quick:
Retrieves all the records for an entity. Calling all
will ignore any constraints on the query.
These two methods will throw a EntityNotFound
exception if the query returns no results.
The findOrFail
method should be used in place of find
, passing an id in to retrieve.
The firstOrFail
method should be used in place of first
, being called after constraining a query.
To get started with Quick, you need an entity. You start by extending quick.models.BaseEntity
.
Alternatively, you can use the quick
virtual inheritance mapping in ColdBox 5.2+.
Both are equivalent, so use the one you prefer. That's all that is needed to get started with Quick. There are a few defaults of Quick worth mentioning here.
We don't need to tell Quick what table name to use for our entity. By default, Quick uses the pluralized name of the component for the table name. That means for our User
entity Quick will assume the table name is users
. You can override this by specifying a table
metadata attribute on the component.
By default, Quick assumes a primary key of id
. The name of this key can be configured by setting variables._key
in your component.
Quick also assumes a key type that is auto-incrementing. If you would like a different key type, define a function called `keyType` and return the key type from that function.
Quick ships with the following key types:
AutoIncrementingKeyType
NullKeyType
ReturningKeyType
UUIDKeyType
keyType
can be any component that adheres to the keyType
interface, so feel free to create your own and distribute them via ForgeBox.
You specify what columns are retrieved by adding properties to your component.
Now, only the id
, username
, and email
columns will be retrieved.
Note: Make sure to include the primary key (
id
by default) as a property.
To prevent Quick from mapping a property to the database add the persistent="false"
attribute to the property.
If the column name in your table is not the column name you wish to use in quick, you can alias it using the column
metadata attribute.
Quick handles formula, computed, or subselect properties using query scopes and the addSubselect
helper method. Check out the docs in query scopes to learn more.
Quick uses a default datasource and default grammar, as described here. If you are using multiple datasources you can override default datasource by specifying a datasource
metadata attribute on the component. If your extra datasource has a different grammar you can override your grammar as well by specifying a grammar
attribute.
At the time of writing Valid grammar options are: MySQLGrammar
, PostgresGrammar
, MSSQLGrammar
and OracleGrammar
. Please check the qb docs for additional options.
Query scopes are a way to encapsulate query constraints in your entities while giving them readable names .
For instance, let's say that you need to write a report for subscribers to your site. Maybe you track subscribers in a users
table with a boolean flag in a subscribed
column. Additionally, you want to see the oldest subscribers first. You keep track of when a user subscribed in a subscribedDate
column. Your query might look as follows:
Now nothing is wrong with this query. It retrieves the data correctly and you continue on with your day.
Later, you need to retrieve a list of subscribed users for a different part of the site. So, you write a query like this:
We've duplicated the logic for how to retrieve active users now. If the database representation changed, we'd have to change it in multiple places. For instance, what if instead of keeping track of a boolean flag in the database, we just checked that the subscribedDate
column wasn't null?
Now we see the problem. Let's look at the solution.
The key here is that we are trying to retrieve subscribed users. Let's add a scope to our User
entity for subscribed
:
Now, we can use this scope in our query:
We can use this on our first example as well, for our report.
We've successfully encapsulated our concept of a subscribed user!
We can add as many scopes as we'd like. Let's add one for longestSubscribers
.
Now our query is as follows:
Best of all, we can reuse those scopes anywhere we see fit without duplicating logic.
All query scopes are methods on an entity that begin with the scope
keyword. You call these functions without the scope
keyword (as shown above).
Each scope is passed the query
, a reference to the current QueryBuilder
instance, as the first argument. Any other arguments passed to the scope will be passed in order after that.
Occasionally, you want to apply a scope to each retrieval of an entity. An example of this is an Admin entity which is just a User entity with a type of admin. Global Scopes can be registered in the applyGlobalScopes
method on an entity. Inside this entity you can call any number of scopes:
These scopes will be applied to the query without needing to call the scope again.
If you have a global scope applied to an entity that you need to temporarily disable, you can disable them individually using the withoutGlobalScope
method:
Subselects are a useful way to grab data from related tables without having to execute the full relationship. Sometimes you just want a small piece of information like the last_login_date
of a user, not the entire Login
relationship. Subselects are perfect for this use case. You can even use subselects to provide the correct key for subselect relationships. We'll show how both work here.
Quick handles subselect properties (or computed or formula properties) through query scopes. This allows you to dynamically include a subselect. If you would like to always include a subselect, add it to your entity's list of global scopes.
Here's an example of grabbing the last_login_date
for a User:
We'd add this subselect by calling our scope:
In this example, we are using the addSubselect
helper method. Here is that function signature:
You might be wondering why not use the logins
relationship? Or even logins().latest().limit( 1 ).get()
? Because that executes a second query. Using a subselect we get all the information we need in one query, no matter how many entities we are pulling back.
Subselects can be used in conjunction with relationships to provide a dynamic, constrained relationship. In this example we will pull the latest post for a user.
This can be executed as follows:
As you can see, we are loading the id of the latest post in a subquery and then using that value to eager load the latestPost
relationship. This sequence will only execute two queries, no matter how many records are loaded.
Argument
Type
Required
Default
Description
name
string
true
The name for the subselect. This will be available as an attribute.
subselect
QueryBuilder OR Closure
true
Either a QueryBuilder object or a closure can be provided. If a closure is provided it will be passed a query object as its only parameter. The resulting query object will be used to computed the subselect.