Contents tagged with NHibernate

  • Just forget that Repository<T> exists, please.

    If there’s a class that’s caused Orchard users more confusion, bugs, and disappointment than Repository<T>, I’d like to know about it… Generic repositories are a well-known anti-pattern, something that the designers of the Orchard data layer were fully aware of, but decided to use anyway as helpers in the implementation of this piece of code that bridges Orchard’s runtime dynamic type system to nHibernate’s database mappings. The class should arguably have been made internal or private (which is something you won’t hear me say every day), but it wasn’t, and now we’re stuck with it until we get to redesign that part of the platform.

  • Making MiniProfiler work in the Orchard dashboard

    MiniProfiler is a wonderful module. It’s especially good at showing you the select n+1 problems in your Orchard applications. For some reason that is not entirely clear to me, however, it is only active on the front-end. If you have to debug a performance issue in the dashboard, you’re out of luck. Fortunately, the limitation is entirely arbitrary, easy to find, and easy to remove.

  • A better way to play with HQL in Orchard

    In previous posts, I’ve shown how to query Orchard with straight HQL. However, I haven’t provided a good environment to run and debug these queries so far, because I didn’t have one. As a matter of facts, my method to build new queries has consisted in building queries from the projection module, putting a breakpoint at the end of the “DefaultHqlQuery.ToHql” method, and previewing the query in order to steal the query string built by the projection module. To debug, I’ve put the code in custom controller actions, and debugged the exceptions from VS. Not super-convenient.

  • Querying Orchard fields with HQL

    Before projections, the official word on fields was that they weren’t for querying (they are stored in an XML blob on the content item record). Projections enabled field querying for the first time, through special tables that index field contents: Orchard_Projections_DecimalFieldIndexRecord, Orchard_Projections_DoubleFieldIndexRecord, Orchard_Projections_IntegerFieldIndexRecord, and Orchard_Projections_StringFieldIndexRecord. Each table is specialized for one underlying value type.An indexing table has columns for property names and values

  • Getting Orchard content items out of HQL

    I the two previous posts (here and here), I’ve showed how to build HQL queries against the Orchard database. Once you’ve built the query, you’ll want to get results, often in the form of fully-built content items. In lots of cases, you’ll want to paginate the results, for which you’ll need a total count, and detailed results for only the current page. This post will show you how to do all these things.

  • Joining Orchard part records in HQL

    In yesterday’s post, I showed the basics of HQL querying in Orchard. It is by far the most flexible way to  query Orchard’s database, but one thing I didn’t show is how this works in relation to Orchard’s content type system. Querying over records is nice, but if those records are part records, you need to be really careful and check that they correspond to a real content item, that his content hasn’t been archived, and that its publication state is what you need it to be. In order to do that, you’ll have to join with ContentItemRecord and ContentItemVersionRecord. But how do you express joins in HQL in a way that works with Orchard records?

  • Querying Orchard in HQL

    Orchard has two APIs on IContentManager to query content items: Query, and HqlQuery. Query is the older API, but it’s also the simplest. It’s great when you want to perform a simple query such as “get all content items with part TitlePart where the title begins with A”. HqlQuery is a little more advanced, closer to nHibernate APIs, and allows for more complex queries. It was added to build the dynamic queries necessary for Projections. It is still, however, designed around the Orchard content type system, which makes it inadequate for queries that don’t trivially map to content items and parts.

  • Storing non-content data in Orchard

    Dry earthA CMS like Orchard is, by definition, designed to store content. What differentiates content from other kinds of data is rather subtle. The way I would describe it is by saying that if you would put each instance of a kind of data on its own web page, if it would make sense to add comments to it, or tags, or ratings, then it is content and you can store it in Orchard using all the convenient composition options that it offers. Otherwise, it probably isn't and you can store it using somewhat simpler means that I will now describe.

  • Orchard 0.5 is out

    (c) Bertrand Le Roy 2004 Before I joined Microsoft seven years ago, I had spent a couple of years building a Web CMS. It wasn’t open-source unfortunately but the experience convinced me that most public-facing web sites would shortly use some form of CMS. I also forged strong opinions about the right level of component granularity that a CMS must implement.