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

  • Passed the C# 70-483 exam (MCP)

    Passed the C# 70-483 exam (MCP)

    Today, after a few weeks of preparation I passed the C# 70-483 exam and became a Microsoft Certified Professional. Woohoo! :)

    Besides getting a cert, was it worth it? I would say in case of this particular exam – yes. I was already familiar with many topics covered by the exam but it did fill some gaps in my C# knowledge. And I enjoyed learning the new bits. It also did feel like I had to learn some details by hard at some points, which was less enjoyable.

    What did I use to prepare myself? I used the official practice exams from measureup, the 70-483 ref book, the Wrox Certification Toolkit book for this exam, in a few cases the official documentation and of course – StackOverflow. I feel the practice exam was very beneficial, the official ref book was also helpful but in my opinion very badly written. It’s as if the book has no structure and as if the authors didn’t communicate between themselves so that would make sense and so you could learn in some kind of logical order. Instead, the book jumps between topics in an unexpected way. The Wrox book was ok. I didn’t go through it in full detail, but read a few bits and pieces where I felt I wanted to get more details which I haven’t been satisfied with by the ref book. Both books seem to be riddled with various mistakes in code.

    Overall, I’m very happy I studied for this exam and that I passed. If you’re considering doing it – do it, you’ll be happy to learn new things and it isn’t really that hard but be prepared to put some time in it. Good luck! :)

  • 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. :)

  • Enhancing RESTful WebAPI controllers with RPC style endpoints

    Enhancing RESTful WebAPI controllers with RPC style endpoints

    During the setup stage of the new project I’m working on, the decision was made to try and use RESTful WebAPI controllers that would support RPC style endpoints as well. I did a bit of research and found a nice post from Carolyn Van Slyck that explains how this can be achieved by creating a few different routing rules in the WebApiConfig file. I wasn’t however fully satisfied with this approach so I tried to do it in a different way.

    If you follow .net’s WebAPI conventions, you can simply write action methods that start with http verbs (GET, POST, PUT, DELETE) and everything will work out of the box with the default WebApiConfig setup. For example you can name your RESTful action methods something like GetAllProducts, GetProduct, PostProduct, etc… No extra action route attributes (such as RoutePrefix, Route, HttpGet/Post/Put/Delete) are needed for this approach. WebAPI will in this case expect the correct http verb.

    However, as soon as you add a custom action, it will start causing problems (you will start getting the infamous “Multiple actions were found that match the request” response). Say you add CustomGetEndpoint method – this will cause GetAllProducts and GetProduct to not work any more. Luckily by adding a few things we can make it work.

    The first step is to enable attribute routing in your WebApiConfig:

    The second step is to add the RoutePrefix to your controller and to add the Route and http verb attributes to all your custom RPC actions (they of course don’t have to start with “custom” but you can name them whatever you want):

    In this case ProductModel is very simple:

    Keep in mind that if you are using a BaseApiController class which inherits .net’s ApiController, ensure that all your methods are protected. If you make your BaseApiController methods public, this will mess up the routing and you will start getting the “Multiple actions were found that match the request” response (took me long enough to figure that one out!).

    That’s all folks, you can now enjoy both worlds at the same time. Enjoy!

Back to top