CompiledQuery с List.Contains (где ... в списке) функциональность? - PullRequest
Новая
       1

CompiledQuery с List.Contains (где ... в списке) функциональность?

2 голосов
/ 24 сентября 2010

Я пытаюсь написать CompiledQuery с использованием Linq-to-Entities, который заменит хранимую процедуру, которая принимает два параметра массива (в данном случае, разделенных запятыми TEXT). По сути, SQL будет примерно таким: 

*Stored Proc definition*
@ArrayParm1    TEXT,
@ArrayParm2    TEXT
-- etc. 
SELECT [fieldList] 
FROM someTable
WHERE someTable.Field1 IN (SELECT * FROM dbo.fncCSVToTable(@ArrayParm1))
AND someTable.Field2 IN (SELECT * FROM dbo.fncCSVToTable(@ArrayParm2))

dbo.fncCSVToTable создает временную таблицу из одного столбца со значениями массива.

Преобразование этого в скомпилированный запрос Linq-to-Entities не показалось сложным: 

public static Func<EntityContext, List<int>, List<string> IQueryable<EntityType>>
    SomeQuery = 
        CompiledQuery.Compile((EntityContext context, List<int> arrayParm1, 
                               List<string> arrayParm2) =>
            from c in context.SomeTableEntities
            where arrayParm1.Contains(c.Field1)
                && arrayParm2.Contains(c.Field2)
            select new EntityType
            { 
                //projection
            });

Тем не менее, я получаю сообщение об ошибке выполнения, в котором говорится, что параметры Func<> не могут быть списком и поддерживаются только скалярные параметры. Это имеет смысл для меня, но я все еще чувствую, что должен быть способ сделать это в скомпилированном запросе. Кто-нибудь знает, как можно использовать функциональность типа List.Contains или WHERE ... IN в L2E CompiledQuery?

1 Ответ

6 голосов
/ 24 сентября 2010

Я подозреваю, что в сгенерированном SQL для не скомпилированного запроса используется 

WHERE someTable.Field1 In (?, ?, ?)

для трех значений, например ... вместо функции fncCSVToTable.

Теперь одной из задач компиляции запроса является предварительная обработка SQL ... и здесь точный SQL будет зависеть от количества элементов в списках (поскольку для этого потребуется столько параметров запроса). Я подозреваю, что это довольно неловко, потому что это просто не поддерживается.

...