Restrictions

The ColdBox restrictions class allows you to create criterions upon certain properties, associations and even SQL for your ORM entities. This is the meat and potatoes of criteria queries, where you build a set of criterion to match against or in SQL terms, your WHERE statements.

The ColdBox criteria class offers almost all of the criterion methods found in the native hibernate Restrictions class:

If there isn't one defined in the CFML equivalent then don't worry, just call it like is appears in the Javadocs and we will proxy the call to the native Hibernate class for you.

Direct Reference

You can get a direct reference to the Restrictions class via the Base/Virtual ORM services (getRestrictions()), or the Criteria object itself has a public property called restrictions which you can use rather easily. We prefer the latter approach. Now, please understand that the ColdBox Criteria Builder masks all this complexity and in very rare cases will you be going to our restrictions class directly. Most of the time you will just be happily concatenating methods on the Criteria Builder.

// From base ORM service
var restrictions = service.getRestrictions()

// From Criteria Builder
newCriteria().restrictions

Ok, now that the formalities have been explained let's build some criterias.

Building Restrictions

To build our criteria queries we will mostly use the methods in the criteria object or go directly to the restrictions object for very explicit criterions as explained above. We will also go to the restrictions object when we do conjunctions and disjunctions, which are fancy words for AND's, OR's and NOT's. So to build criterias we will be calling these criterion methods and concatenate them in order to form a nice DSL language that describes what we will retrieve. Once we have added all the criteria then we can use several other concatenated methods to set executions options and then finally retrieve our results or do projections on our results.

Adobe ColdFusion may throw an "Invalid CFML construct" error for certain CBORM methods that match reserved operator names, such as .and(), .or(), and .eq(). You can use .$and(), .$or(), and .isEq() to avoid these errors and build cross-engine compatible code.

In some cases (isEq(), isIn(), etc), you may receive data type mismatch errors. These can be resolved by using JavaCast on your criteria value or use our auto caster methods: idCast(), autoCast()

c.isEq("userID", idCast( 3 ) );

You can also use the add() method to add a manual restriction or array of restrictions to the criteria you are building.

c.add( c.restrictions.eq("name","luis") )

But as you can see from the code, the facade methods are much nicer.

Dynamic Negation

Every restriction method you see above or in the docs can also be negated very easily by just prefixing the method with a not .

c
    .notEq("userID", idCast( 3 ) )
    .notBetween()
    .notIsTrue()
    .notIsFalse();

Fluent If Statements - when()

There comes times where you need some if statements in order to add criterias based on incoming input. That's ok, but we can do better by adding a when( test, target ) function that will evaluate the test argument or expression. If it evaluates to true then the target closure is called for you with the criteria object so you can do your criterias:

newCriteria()
    .when( isBoolean( arguments.isPublished ), function( c ){
        // Published process
        c
            .isEq( "isPublished", isPublished )
            .when( isPublished, function( c ){
                c.isLt( "publishedDate", now() )
                .$or( 
                    c.restrictions.isNull( "expireDate" ), 
                    c.restrictions.isGT( "expireDate", now() ) 
                )
                .isEq( "passwordProtection","" );
            })
        }
    } )
  .when( !isNull( arguments.showInSearch ), function( c ){
          c.isEq( "showInSearch", showInSearch );
   } )
   .when( arguments.isActive, function( c ){
            c.isTrue( "isActive" );
   })
  .list()

Last updated