• Filtering collections by multiple field values in LLBLGen Pro ORM

    Filtering collections by multiple field values in LLBLGen Pro ORM

    Sometimes we need to fetch a very specific subset of records from the database. For example when we already have a list of specific Id’s of records that we need to fetch. That’s what this post will cover.

    To accomplish this kind of filtering with LLBLGen we need to use the FieldCompareRangePredicate. It’s usage is very similar to the FieldLikePredicate from the previous post of the series.

    That’s it. If you have any questions, leave them bellow. Enjoy!


  • Filtering collections by LIKE operator in LLBLGen Pro ORM

    Filtering collections by LIKE operator in LLBLGen Pro ORM

    This will be a simple one. It’s another useful way of filtering entity collections in LLBLGen Pro. If you don’t know anything about filtering, predicate expressions or buckets in LLBLGen, check out some of the previous posts from the series.

    What the LIKE operator enables us to do in SQL is it allows us to filter collections by partial string matches which is a quite common action if you have any search input fields in your app. For example if we wanted to find all the products that have the word “blue” in their name we would use the LIKE operator. The way to do it in LLBLGen would be to use the FieldLikePredicate:

    There really isn’t much more to it, it’s pretty straightforward and simple.

    Hope it helped. If you have any questions or comments, drop them below. Cheers!


  • Filtering nested entities with LLBLGen Pro ORM

    Filtering nested entities with LLBLGen Pro ORM

    In this post, we’ll cover how to filter nested entities when fetching either a single entity or a collection of entities. How is this different from the second filtering example from the previous post? Well, in the previous post we demonstrated how to filter main entities BY fields of related tables. This post explains how to filter nested entities, or how to choose which nested entities to prefetch.

    Again we’ll use the same DB schema from previous LLBLGen posts (made using QuickDBD):

    What we need to do is simply create a PredicateExpression and add it to the prefetchPath:

    The second example demonstrates how to use a RelationPredicateBucket instead of a PredicateExpression if you need to filter nested entities by multiple fields or if you need to filter by sub-nested entities (i.e. products). If you don’t have to add any bucket relations, you can omit the last param.

    Also, keep in mind you can add these predicates/buckets to prefetches whether you’re fetching a single or a collection of entities.

    Feel free to leave a comment or ask a question below.

  • Filtering entity collections with LLBLGen Pro ORM

    Filtering entity collections with LLBLGen Pro ORM

    In the previous post, we covered the topic of fetching nested entities (prefetching) and in this one we’ll go over filtering entity collections. When talking about databases, filtering is one of the most commonly used operations. In LLBLGen, filtering means using predicate buckets.

    We’ll re-use the same DB schema throughout the whole LLBLGen series (made using QuickDBD):

    We’ll cover two ways of filtering in this post. In the first one we’ll filter by a field on the main entity of the collection (we’ll filter products by price). In the second one we’ll filter by fields of related entities (for instance, let’s filter all orders created by customers named “Joe”).

    Please note that in addition to a predicate expression, for the second filter we also had to define a relation. If we didn’t do it, we’d get a runtime error because we would have a mismatch between the entity collection type and the entity type of the field that we’re filtering by.

    In the following posts, we’ll cover additional filtering scenarios which are maybe not as common as this one, but you’ll still bump into them from time to time.

    I hope this was helpful and if you have any questions, please drop a comment.


  • Fetching nested entities with LLBLGen Pro ORM

    Fetching nested entities with LLBLGen Pro ORM

    In this post, I’ll quickly explain how to fetch “nested” (related) entities with LLBLGen Pro ORM framework. In LLBLGen this operation is called prefetching. By adding prefetch paths, we’re telling LLBLGen which related entities we want it to fetch from the database together with our main entity. These prefetched entities will be easily accessible as properties (and/or) sub-properties of the main object.

    Let’s take the following DB schema as an example (diagram made using QuickDBD):

    The code below contains two simple examples of prefetching based on two different starting points (with OrderEntity and then CustomerEntity as the starting entity).

    In the first example we’re prefetching multiple entity types related to the OrderEntity (CustomerEntity and ProductEntity). In the second example we’re starting with the CustomerEntity, then we’re prefetching all the OrderEntity objects and then multiple sub-entities related to the already prefetched OrderEntity (ProductEntity and OrderStatusEntity).

    I envisioned this as a short series of blog posts focusing on fetching and filtering concepts which you’ll find yourself using every day wiht LLBLGen. In the following posts we’ll cover a couple of different filtering techniques depending on what you need to filter your entity collections by.

    Hope you found the post helpful. If you have any questions, drop a comment bellow. Cheers!

  • Mocking AngularJS promise callback params in Jasmine tests

    Mocking AngularJS promise callback params in Jasmine tests

    You could argue that in a scenario such as this one, you should ideally have a separate, stand-alone callback function to handle the success response of a promise, but this post is not about that. It’s about an occasional need to mock a promise and perhaps it’s callback params in Jasmine unit-tests and this is a simple example of how it can be done.

    This is an example of a function you might find in an AngularJS controller (written in TypeScript, but doesn’t matter, it would be almost identical in JS).

    It contains a call to a service function which in turn returns a promise. That promise returns a successResponse and that’s what we’re about to mock. What we want to test is a situation where a $http request didn’t fail, but it didn’t return any data either. In that case, we might want to display a toast message and skip refreshing the local cache.

    The following Jasmine test explains the code in-line. Two crucial parts are creation of the promise and how to resolve it and forcing the angular digest cycle with $rootScope.$apply(). The $apply() is needed because we’re invoking the promise from the Jasmine side, which is sort of “from the outside” and AngularJS will not be aware of that the event occurred so we need to let it know manually (the promise resolution wasn’t triggered by AngularJS itself internally).

    Hope that helps. If you know of an easier way to do this, please let me know in the comments. Thanks!


Back to top