IDTable (breaking) changes in 5.1.1.8

Having been using 5.1.1.4 for a while on a project, version 5.1.1.8 was a somewhat eagerly awaited release.

We rely heavily on the use of external data sources for this project (well any project), and the 5.1.1.4 release offered some very nifty options in this regard - specifically the IDTable class. But unfortunately, not everything regarding external datasources and IDTable mapping was quite "in place" in 5.1.1.4. We experienced issues of what looked to be endless recursion, template editor hanging and similar. To start with something positive - this is all fixed in 5.1.1.8 :-) Or atleast, I've experienced no such issues - and I used to get them more or less all the time.

On the downside - IDTable is broken at this time. Apparently part of the solution to the above problems was, to introduce a new layer of ID mapping (atleast that's the only answer I can come up with) - meaning that any external object would be mapped ONCE against Sitecore in general - then a multitude of times for each Shadow Copy made of the object. To do this, a new field "ItemID" was introduced in the Master database on the IDTable table. All of this is probably good and well, except noone can really have been putting this through extensive testing ;-) Because the IDTable code hasn't changed. It still works on the 5.1.1.4 fields ID, Prefix, Key, ParentID and CustomData. And since the new column ItemID doesn't allow nulls, you're going to run into an SqlException whenever you attempt to add new mappings using IDTable.Add(). Fortunately, there's a few options one can do to fix this. An obvious choice is to remove the column entirely. As far as I can tell, there's no place in Sitecore that uses this field yet - this option was also suggested from Sitecore Support.

Alternatively you could implement a default value for the field - or simply set it to allow NULLS. As I don't fully know what functionality this field is going to be supporting in the future, I cannot predict which of these 3 solutions will be best in the long run. I expect this issue to be resolved soon enough, anyhow :-) We're using SqlServer databases by the way, I don't know if the Firebird implementation has similar issues.