The following code fetches a set of company IDs from a database if there are any events associated with a company that has a missing property. Because the set of company IDs is embedded into the SQL query using parameters, and the number of parameters may exceed the maximum for the RDBMS / database driver, the set is partitioned into maximal subsets.
Performance aside, in terms of maintainability and ability to debug, is the following "too Linq-y"?
HashSet<int> missingCompanyIds = companyEvents .Select(ev => ev.CompanyId).ToHashSet() .Partition(DataContext.MaxAvailableSqlParameters(usedParameters), true) .SelectMany(companyIdsPartition => missingEventsQuery // linq-to-sql .Where(ev => companyIdsPartition.Contains(ev.CompanyId)) // linq-to-sql .Select(ev => ev.CompanyId) // linq-to-sql .Distinct()) // linq-to-sql .ToHashSet();
If any of the database side-effects of the query methods cause a crash, perhaps this is harder to debug, I don't know. I am able to set breakpoints inside lambdas, but my local environment might contain fewer of the objects I wish to inspect when debugging (e.g. the
missingEventsQuery)? I'm unsure if these concerns would be relevant in practice.
Would there be any advantages in the case above if some of the
.Select()s were written as for loops?