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

  • InfluxDB Studio

    InfluxDB Studio

    It feels great when someone uses something you made and thinks it’s good. Every now and then someone creates a pull request for the InfuxData.Net lib I made and have been maintaining. It’s sort of a nice confirmation of your efforts and makes you warm and fuzzy on the inside. :D

    Well, this guy named meverett recently made a few pull requests with fixes and some nice lib improvements AND then told me that he’s actually using the library to make an InfluxDB database management studio (sort of what SQL Management Studio is for SQL, but for InfluxDB)!

    I find the admin dashboard that comes with InfluxDB a bit too simplistic and buggy and was actually thinking about how useful it would be if only there was a proper management app for Influx. Well, the InfluxDB Studio does more than the web admin dashboard and works great. And it made me really happy! :D

    This is how it looks:

    Thanks for the great work meverett!

  • Contributing back – InfluxData.Net NuGet

    Contributing back – InfluxData.Net NuGet

    On project that I currently work on in Dovetail, we’re using the InfluxDb time-series database. And it’s a really cool thing to be working with.

    Recently we had to move to a newer version of InfluxDb and the library that we were using at the time became a bit stale and didn’t support the newest version of InfluxDb (v0.9.6) which we had to move to. So, partially out of necessity, and partially “because I can” and wan to, I decided to update the currently existing library and then re-release it as a NuGet package under a slightly different name.

    *drumroll* – the code for the InfluxData.Net NuGet is available on Github. It already had a few code contributions which is quite exciting. The whole codebase has been refactored, additional tests written and I believe that the codebase is now quite stable. I plan on expanding the library API to support most of the stuff that InfluxDb provides, and I also plan on implementing the API’s for other InfluxData products such as Kapacitor and Telegraf.

    If people keep using it in the future, I’ll consider it a success and it will make me happy. :)

Back to top