for the most part the syntax for the call is equivalent to what is was before so go to my previous article regarding that (check out the old article for details). What I’ve added this time around is:

• the @PropertyName can be declared as ‘%’ if you want to look in all property names
• @PropertyType can be –1 if you want to look in all property types otherwise you need to specify type id (this has changed from type name before due to database schema changes)
• additionally this version of the stored proc will only look in the Master language Branch, so it will work for the single language pages and for multi-language but for language agnostic properties. (should you require the language to be variable the change is pretty simple – I can send you the updated version by email.

/****** Object:  StoredProcedure [dbo].[PagedSearch]    Script Date: 07/07/2009 12:18:10 ******/
IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[PagedSearch]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[PagedSearch]
GO

CREATE Procedure PagedSearch
    @Condition varchar(1024),
    @PropertyName varchar(1024),
    @PropertyType int,
    @PageSize int,
    @PageNumber int,
    @Offset int
AS
BEGIN

    DECLARE @RowStart int
    DECLARE @RowEnd int

    SET @RowStart = @PageSize * @PageNumber + @Offset;
    SET @RowEnd = @RowStart + @PageSize + @Offset;

    WITH PageRefs AS
        (SELECT page.pkID as PageId,
            ROW_NUMBER() OVER (ORDER BY pageLang.StartPublish DESC) as RowNumber
            FROM tblPage page, tblProperty propValue, tblPageDefinition propDef, tblPageLanguage pageLang
            WHERE page.pkID = propValue.fkPageID
                AND page.fkMasterLanguageBranchID = pageLang.fkLanguageBranchID
                AND page.pkID = pageLang.fkPageID
                AND propValue.fkPageDefinitionID = propDef.pkID
                AND (@propertyType = -1 or propDef.fkPageDefinitionTypeID = @propertyType) -- is proper type
                AND propDef.Searchable = 1 -- the property is searchable
                AND propValue.String like @Condition -- contains facets
                AND propDef.[Name] like @PropertyName) -- property of proper name
    SELECT PageId
        FROM PageRefs
        WHERE (RowNumber Between @RowStart and @RowEnd) or (@PageSize = 0);
END
GO

However… looking how the schema has changed over time, I am not convinced this approach is really the best one for someone who is not prepared to deal with the changes (e.g. you better be able to change the stored procedure based on the schema changes – or bribe me with pizza and beers for updates :) ).

Additionally this procedure only searches for properties that store their value in Short string field. To make it look into long string you need to Change the highlighted line to.

AND (propValue.LongString like @Condition)

or alternatively to look in both change it to:

AND ((propValue.String like @Condition) or (propValue.LongString like @Condition))

Enjoy!

Well I have… and I’m sure I will. And so did Fredrikj on the our #epicode IRC channel ;).

Basically I had the tool that would convert from one language to another, but Fredrikj requested something that would switch master language of a page from one to another. Since I’ve already had some of the work done, I’ve updated the stored procedure I’ve written some time ago and slapped a nice GUI up on it. Here’s the result:

What the tool allows you to do is perform either language conversion or master branch switching on a selected page and all of its children (if you choose so).

The stored procedure have been updated to work on CMS5 R2 (will no longer work on R1 – but if you need that functionality, comment here or give me a shout and I’ll create a compatible version for you).

A word of caution though – I take no guarantee whatsoever about its operation. Especially, if you wreck your client’s database with it. I did what I could to prevent some of the obvious problems (like switching to a non existing master or converting to an existing one) but I will not be responsible if it won’t work for you. make a database backup and experiment there before you do any changes on the real data. That said – it works for me, so I think it should also work for you.

You can download the archive containing the tool here. unzip it to your EPiServer web application folder keeping the folder structure or the plugin reference will be wrong. Include the *.aspx and the *.cs files in your project and apply the SQL file to your database (The manipulation is performed by a stored procedure located in the file).

Also if you’re performing the change in a load balanced environment, you may need to restart the other servers once you do the changes. I reset the DataFactory cache, but I am not sure it propagates through to other servers.

One of the first projects (that I took part in) is CogniScale – an app that allows FlexiScale users to manage their servers. Here’s the story…

Being the agile company taking part in many EPiServer projects we never seem to have enough environments to test our web-apps and software in general in various scenarios. We find ourselves constantly reinstalling and trying to keep our servers in a state that can can at least remotely be called as stable. After all how many deployments and tearing down of various EPiServer, CruiseControl, TeamCity, SQL Server and other "I need to have" apps can a server take before slowing down to a crawl or collapsing all together (that said I bow before our faithful THOTH for taking all the abuse it does). We definitely needed more servers! And we needed them now!

Early this year we’ve started to talk to the guys at XCalibre that came up with a great idea. What if you could have an unlimited amount of servers available for you at any given time? I mean really what if you could have 0 servers one day and the next day have a rich farm of servers for literally no cost, paying only when you power them up and not paying a bit if you take them down.  This turned out to be quite a project for them that turned to materialize as FlexiScale. (you can read more about it here). Looking at all that I’ve mentioned before while eliminating the cost of maintaining the servers locally we decided to give FlexiScale a spin.

Early this year FlexiScale published a set of API’s that we looked at and (being the geeks we are) tried to utilize it in a desktop application with a limited success. It turned out that the initial API was perfectly accessible from dynamically typed languages while statically typed languages like C# didn’t really get their love in the initial release :) So we started opening the support tickets and shortly after that establishing a lively dialogue with the great folks there. Let me tell you, the guys in the FlexiScale support are really an amazing and responsive bunch. Not only did we get the support and the fixes we needed for the language we chose but we also pretty much got all our suggestions implemented and added to the API’s.

Thus CogniScale was born:

The app allows for easy powering up and down the servers (allowing you to describe the reason for the action) from a nice and shiny GUI as well as scheduling it with windows task scheduler through its command line interface. it allows you to connect using FTP or Remote Desktop as well as any other app you can run from command line (it features a custom command editor that allows you to configure any app to work with it) with a single click. The app also allows you to quickly go through the history of servers’ maintenance to determine how often and for what reason were they taken on and off-line.

Should you decide that FlexiScale is your thing, please give CogniScale a whirl and let us know what you think.

This article is a first of a series describing the faceted navigation system for EPiServer that we have internally developed in Cognifide and that’s already proven to be a robust solution for delivering tagged content a heavy traffic site, which will be released shortly as an open source project. The article outlines some pitfalls of EPiServer that we’ve run into and the nature of the project in which the module was used first and which influenced a lot of our design decisions.

This article and the Faceted Navigtation module is developed on EPiServer 4.61 and not the latest version 5 of the CMS so far, so mind that some of my reservations may not be a problem if you’re just starting to work on a brand new project and have the luxury of using new features of it.

Also (which may be a good thing) our sites uses a different approach to navigation the content, we do not really care much for the tree structure, but we treat all EPiServer pages equally when looking for content because of how the site is designed from the creative point of view.

The project is a vast site with:

• tens of editors working on it simultaneously.
• millions of uniques per month
• tens of thousands of articles in just about half a year
• 5 IIS servers working in tandem on a single SQL database
• The page cannot be cached as a whole as it contains dynamic and Geo-targeted content.
• The content on the page changes every other minute or more often
• There is a great deal of automated content coming from various feeds.
• A content can be both feeded automatically based on the time of publishing as well as forced in some controls and no article can appear on a page twice, yet controls have to have predefined number of links. May not seem hard to do, but believe me once controls will start stealing articles form each other you’ll see why I listed it as a main feature.

First thing to give the credit where it’s due – let me enumerate the good sides of using EPiServer in the scenario (the parts that we found particularly useful):

• EPiServer provides a beautiful interface to the editors. Both for editing pages and organizing the content.
• EPiServer provides a great infrastructure for us to plug into it with property types, and GUI plugins
• EPiServer allows us to use as much or as many of its elements as we need – from our point of view we mostly use it as a repository and pretty much ignored all of its custom controls and a great deal of its APIs (which I’ll explain later why.

The list does not seem like a long one – but believe me – all of the points are fundamental to the success of the site! The editors love the UI, the developers love the extensibility and “pluggability” of the APIs. And the logical structure of the database allowed us for flexibility in skipping some APIs where it proved that a direct database call was beneficial.

The bad part is basically that the EPiServer API is slow for what we needed it to perform (the site can easily reach a couple of thousand simultaneous connections at peak times), if we wanted to use GetPage() for every link on the site we would be in serious troubles.  At our average of 155 links per page, this was a serious problem.

Also since we have a structure of the tree that is not directly reflected on the site, but rather we search by “categories”. The idea of the site is that it is a huge search engine that displays the freshest content content based on the facets it is tagged with. Using the EPiServer APIs we would have to use FindPagesWithCriteria() which in itself is probably the most disliked call speed-wise. Also categories in themselves do not support any metadata (there are no properties for categories). Needless to say – we had to implement our own code for this kind of creative approach and that’s what we did.

In effect, what we limited to the list of hardest abusers are:

• FindPagesWithCriteria()
• Getpage()
• GetChildren()
• and (mostly based on Mat’s article) use of dynamic properties.

Basically all the calls that return PageData or PageDataCollection are all potential candidates for heavy caching.

The main approach that we took in our solution is “cache the hell out of it, but do it smart”. Don’t cache PageData unless there is absolutely no other way. Cache links, page titles and data that’s potentially used on every page.

Also where needed and justified by the speed increase we reach directly to the database – skipping some EPiServer APIs (At this point this is just one call as we want the solution to be easily portable between various EPiServer versions).

More (and the solution) coming shortly…

Found it hilarious enough though to post it here though :)

“This indicates a bug in your application”, how vicious of them show a dialog like this to a developer. It’s not in MY code you bad thing you! It’s in YOUR code!

The solution or rather a workaround is available here. And NO, you don’t need to restart your computer after applying the change to the registry, just kill and restart Explorer and then start the Tuning advisor again. Make sure to restart the SQL Server Management Studio as well if you’re launching the tuning advisor form it, the setting is applied on app startup.

Theoretically in EPiServer you can pull the pages that match the criteria from the database with EPiServer.Global.EPDataFactory.FindPagesWithCriteria() into the PageList but that seemed to be imposing a strong performance penalty with increased number of pages meeting the criteria. Since this search is sometimes done even multiple times on a page request in our project we needed something better.

CREATE Procedure PagedSearch
    @Condition varchar(1024),
    @PropertyName varchar(1024),
    @PropertyType varchar(1024),
    @PageSize int,
    @PageNumber int,
    @Offset int
AS
BEGIN
    DECLARE @RowStart int
    DECLARE @RowEnd int

    SET @RowStart = @PageSize * @PageNumber + @Offset;
    SET @RowEnd = @RowStart + @PageSize + @Offset;

    WITH PageRefs AS
        (SELECT page.pkID as PageId,
            ROW_NUMBER() OVER (ORDER BY page.StartPublish DESC) as RowNumber
            FROM tblPage page, tblProperty propValue, tblPageDefinition propDef
            WHERE page.pkID = propValue.fkPageID
                AND propValue.fkPageDefinitionID = propDef.pkID
                AND propDef.fkPageDefinitionTypeID = @propertyType -- is proper type
                AND propValue.Searchable -- the property is searchable
                AND propValue.String like @Condition -- contains facets
                AND propDef.[Name] = @PropertyName) -- property of proper name
    SELECT PageId
        FROM PageRefs
        WHERE (RowNumber Between @RowStart and @RowEnd) or (@PageSize = 0);
END

The procedure searches the database and return the results on a chunk specified by @PageNumber, where each chunk is of size specified by @PageSize. If e.g. on the first page you only have a place for first 3 articles you can specify an @Offset for the “Next page >>”, otherwise you can set the @offset to 0.

With a little effort you can adapt this stored procedure to do your job or just paged search outside of EPiServer. From the EPiServer point of view however you might find it a caveat, that you need to create your own paged repeater and query the server for the number of pages, which can be done easily with another variant of this stored procedure that asks for count of the same result set and divides it by a number of pages. But then again, if you want it to be done right, it’s usually no substitute to the long way round.

The stored procedure skips a lot of the complexity that it should probably have – meaning it only provides the search in reverse chronological order and disregards whether the page expired as well as any globalization settings, this has been omitted since I did not need it in my project and didn’t really want to add it here not to loose the clarity of the paged searches in Microsoft SQL Server. Just a place to start.