После копания и отладки я выяснил, что рабочий код:
update(value){
this.treeData = value;
this.dataSource.data = this.treeData;
for(let itemG of this.treeData) {
for(let item of itemG.children.value) {
if(item.checked) {
this.checklistSelection.toggle(item);
}
}
}
}
и все работает, как и ожидалось:)
Кто-нибудь может предложить лучшее решение?
У меня была эта точно та же самая проблема, мой запрос занимал 40 секунд.
Я нашел, что проблема была с .Include("table_name")
функции. Чем больше из них, которые я имел, тем хуже это было. Вместо этого я изменил свой код на Ленивую Загрузку все данные, в которых я нуждался прямо после запроса это снесло общее время приблизительно к 1,5 секундам с 40 секунд. Насколько я знаю, это выполняет ту же самую вещь.
Таким образом для Вашего кода это было бы что-то вроде этого:
var groupQuery = (from g in context.Groups
where g.GroupKey == 6
select g).OfType<Deal>();
var groups = groupQuery.ToList();
foreach (var g in groups)
{
// Assuming Dealcontract is an Object, not a Collection of Objects
g.DealContractReference.Load();
if (g.DealContract != null)
{
foreach (var d in g.DealContract)
{
// If the Reference is to a collection, you can just to a Straight ".Load"
// if it is an object, you call ".Load" on the refence instead like with "g.DealContractReference" above
d.Contracts.Load();
foreach (var c in d.Contracts)
{
c.AdvertiserAccountType1Reference.Load();
// etc....
}
}
}
}
Кстати, если бы необходимо было добавить эту строку кода выше запроса в текущем коде, то это снесло бы время приблизительно к 4-5 секундам (все еще также морской налим в моей опции) Из того, что я понимаю, MergeOption.NoTracking
опция отключает большое отслеживание наверху для обновления и вставки материала назад в базу данных:
context.groups.MergeOption = MergeOption.NoTracking;
Это из-за Включения. Мое предположение - то, что Вы - нетерпеливая загрузка большого количества объектов в память. Это занимает время для создания объектов c#, который соответствует объектам дб.
Моя рекомендация для Вас состоит в том, чтобы попробовать к ленивой загрузке только данные, в которых Вы нуждаетесь.
Единственный способ сделать начальную компиляцию запроса быстрее, что я знаю о, состоит в том, чтобы сделать запрос менее сложным. Документация MSDN относительно соображений производительности для Платформы Объекта и Скомпилированных Запросов не указывает, что существует любой способ сохранить скомпилированный запрос для использования на другой сессии выполнения приложений.
Я добавил бы, что мы нашли, что наличие большого количества из Включает, может сделать выполнение запросов медленнее, чем наличие, меньше Включают и выполнение большего количества Нагрузок на связанные объекты позже. Некоторый метод проб и ошибок требуется, чтобы находить правильный носитель.
Однако я должен спросить, нужно ли Вам действительно каждое свойство каждого объекта, Вы включаете здесь. Мне кажется, что существует большое количество различных типов объекта в этом запросе, так осуществление их могло быть довольно дорогим. Если Вы просто пытаетесь получить табличные результаты, которые Вы не намереваетесь обновить, проектируя (относительно) меньше количества полей, в которых Вы на самом деле нуждаетесь в плоский, анонимный тип, должно быть значительно быстрее по различным причинам. Кроме того, это освобождает Вас от необходимости волноваться о нетерпеливой загрузке, вызове Load/IsLoaded, и т.д.
Можно, конечно, ускорить начальное создание представления путем предварительной компиляции представлений объекта. Существует документация относительно MSDN для этого. Но так как Вы оплачиваете ту стоимость в то время, когда первый запрос выполняется, Ваш тест с простым запросом показывает, что это работает в окружении 2 секунд для Вас. Хорошо сказать, что 2 секунды, но это не сохранит ничто больше.
EF требует времени к запуску. Это должно создать метаданные из xml и вероятно генерирует объекты, используемые для отображения. Таким образом, требуется несколько секунд для запуска, я не думаю, что существует способ обойти это, кроме никогда перезапуска программы.