DotNetNuke 6.2.0 introduces changes to how the Tab (Page) Hierarchy is managed.
Due to the limitations of earlier versions of SQL Server, which we were required to support prior to DNN 5.4, the business layer had to manage the handling of the page hierarchy. Whenever a page (tab) was created or moved in the hierarchy, there was a lot of calculation to calculate the effect on other pages and update them accordingly.
In a large site like this one - if a page with a large number of descendants is updated then every descendant is updated so that its "Level" and "TabPath" can be updated in the database.
SQL Server 2005 introduced the concept of "Common Table Expressions" or CTEs, which allow you to create recursive SQL scripts with fairly decent performance. Since we now require at least SQL Server 2005 as our base version of SQL Server, we have removed the Level and TabPath columns from the Tabs table and instead calculate them "on-the-fly" in the Tabs View.
WITH RecursiveTabs (TabID, Level, TabPath)
AS
(
SELECT
TabID,
0 AS Level,
CAST('//' + dbo.dnn_RemoveStringCharacters(TabName, '&? ') AS NVARCHAR(255)) AS TabPath
FROM dnn_Tabs
WHERE ParentId IS Null
UNION ALL
SELECT
T.TabID,
Level + 1,
CAST(TabPath + '//' + dbo.dnn_RemoveStringCharacters(TabName, '&? ') AS NVARCHAR(255))
FROM dnn_Tabs T
INNER JOIN RecursiveTabs R ON T.ParentId = R.TabID
)
This now means that we don't have to do all the manipulation in the business layer in order to manage these properties.
In addition to removing the two columns from the database table, we pushed more of the logic for creating and moving pages into more specific stored procedures e.g. MoveTabBefore, MoveTabAfter etc., which are 1:1 mappings to the API methods in TabController. A few methods in TabController that are no longer necessary have been deprecated and a few new ones created.
To give an example of the effect of these changes - consider a page with 20 child pages. To move one of those child pages (in the Page Management module) to the top triggered 166 calls to the database in 6.1.2. In 6.2.0 this move triggers 5 calls to the database, and the guts of the work is done in a single stored procedure MoveTabBefore.
For the most part this change does not affect 3rd party developers unless they are manipulating pages directly in the Tabs table in the database. As long as you are using the API or are working with the vw_Tabs database View then everything should continue to work. However, both the performance and reliability of moving tabs is now enhanced significantly, as everything is encapsulated in a single stored procedure.