You may see this when attempting an update in Team Foundation Server: ..."could not update the work item because it was already updated by another user, it does not exist, or you do not have permission to update it."
One way around this problem:
We have a new consensus on LinqSpec in that it is understood that is not a bad approach to building queries. Specifications can break NHibernate in scenarios such as:
x = > myGuidCollection.Contains(x.Id)
...but instead of these being viewed as pitfalls it is more appropriate to understand that the burden is still upon us to craft queries appropriately.
Using .Contains in a LinqSpec Specification can create a query that NHibernate will not be able to support. The trouble comes when the .Contain trails an empty collection. I learned the hard way that this...
public static Specification<ProgramOffering> ProgramAndProgramPlanCriteria(
IList<Guid> programIds, IList<Guid> programPlanIds)
{
var programPlanSpec = new AdHocSpecification<ProgramOffering>(
po => programPlanIds.Contains(po.ProgramPlan.Id) ||
programIds.Contains(po.ProgramPlan.Program.Id));
return programPlanSpec;
}
...had to be refactored to this...
public static Specification<ProgramOffering> ProgramAndProgramPlanCriteria(
IList<Guid> programIds, IList<Guid> programPlanIds)
{
List<Guid> programAndProgramPlanIds = new List<Guid>(){};
programAndProgramPlanIds.AddRange(programIds);
programAndProgramPlanIds.AddRange(programPlanIds);
var programPlanSpec = new AdHocSpecification<ProgramOffering>(
po => programAndProgramPlanIds.Contains(po.ProgramPlan.Id) ||
programAndProgramPlanIds.Contains(po.ProgramPlan.Program.Id));
return programPlanSpec;
}
...to account for situations in which one of the two collections handed in was flawed as hinted at here.
