Как загрузить локальную переменную JSON с использованием таблицы данных jquery

У меня есть локальный набор данных JSON. Я хочу использовать jquery данных плагин, чтобы отобразить его. Существует ли какая-либо настройка или конфигурация внутри подключаемого модуля с таблицей данных для отображения данных? Все, что я могу найти, это делать вызовы AJAX и вызовы сервера.

Спасибо за помощь.

-121--924384-

Запрос к хранилищу RavenDB каталога продуктов для сбора данных по произвольной коллекции продуктов Это продолжение проекта, описанного в данном вопросе. У меня есть следующая модель: класс Product {public последовательность Id {get; набор;} общедоступная последовательность [] Спецификации {get; набор;} public int...

Это продолжение проекта, описанного в этом вопросе.

У меня есть следующая модель:

class Product {
  public string Id { get; set; }
  public string[] Specs { get; set; }
  public int CategoryId { get; set; }
}

В массиве «Specs» хранятся пары значений имен спецификаций продукции, соединенные специальным символом. Например, если продукт окрашен в синий цвет, последовательность спецификации будет «Color ~ Blue». Представление спецификаций таким образом позволяет запрашивать продукты, имеющие несколько значений спецификаций, заданных запросом. Есть два основных запроса, которые я хотел бы поддержать:

  1. Получить все продукты в данной категории.
  2. Получите все продукты данной категории, которые имеют набор указанных спецификаций.

Это хорошо работает с RavenDB. Однако в дополнение к продуктам, удовлетворяющим заданному запросу, я хотел бы вернуть результирующий набор, который содержит все пары имя-значение спецификации для набора продуктов, указанного запросом. Пары имя-значение спецификации должны быть сгруппированы по имени и значению спецификации и содержать количество продуктов, которые имеют заданную пару имя-значение спецификации. Для запроса № 1 я создал следующий индекс уменьшения карты:

class CategorySpecGroups {
    public int CategoryId { get; set; }
    public string Spec { get; set; }
    public int Count { get; set; }
}


public class SpecGroups_ByCategoryId : AbstractIndexCreationTask
{
    public SpecGroups_ByCategoryId()
    {
        this.Map = products => from product in products
                               where product.Specs != null
                               from spec in product.Specs
                               select new
                               {
                                   CategoryId = product.CategoryId,
                                   Spec = spec,
                                   Count = 1
                               };

        this.Reduce = results => from result in results
                                 group result by new { result.CategoryId, result.Spec } into g
                                 select new
                                 {
                                     CategoryId = g.Key.CategoryId,
                                     Spec = g.Key.Spec,
                                     Count = g.Sum(x => x.Count)
                                 };
    }
}

Затем я могу запросить этот индекс и получить все пары имя-значение спецификации в данной категории. Проблема, с которой я сталкиваюсь, состоит в том, чтобы получить один и тот же результирующий набор, но для запроса, который фильтрует как по категории, так и по набору пар имя-значение спецификации. При использовании SQL этот результирующий набор будет получен путем создания группы по набору продуктов, отфильтрованных по категориям и спецификациям. Как правило, этот тип запросов является дорогостоящим, но при фильтрации по категориям и спецификациям наборы продуктов обычно малы, хотя и недостаточно малы для размещения на одной странице - они могут содержать до 1000 продуктов. Для справки, MongoDB поддерживает метод group , который может использоваться для достижения того же набора результатов. Это выполняется на стороне сервера ad hoc grouping, и производительность является приемлемой.

Как получить этот тип результирующего набора с помощью RavenDB?

Одним из возможных решений является получение всех продуктов для запроса и выполнение группировки в памяти, а другим вариантом является создание индекса сокращения, как описано выше, хотя задача с этим будет заключаться в выводе всех возможных выборок спецификаций, которые могут быть сделаны для данной категории и дополнительно,этот тип индекса может расчлениться по размеру.

В качестве примера рассмотрим эту страницу категории крепежа . Пользователь может фильтровать свой выбор, выбирая атрибуты. Когда атрибут выбран, он сужает выбор продуктов и отображает атрибуты в новом наборе продуктов. Этот тип взаимодействия обычно называется фасетным поиском .

EDIT

В то же время я буду пытаться найти решение, используя Solr , поскольку они поддерживают выборочный поиск.

EDIT 2

Похоже, что RavenDB также поддерживает фасетный поиск (что, конечно, имеет смысл, индексы хранятся Lucene так же, как Solr). Я буду изучать это и публиковать обновления.

EDIT 3

Функция фасетного поиска RavenDB работает так, как ожидалось. Я храню документ настройки фасета для каждого идентификатора категории, который используется для вычисления фасетов для запроса в данной категории. Проблема, которую я сейчас имею, это производительность. Для набора из 500 000 продуктов с 4500 различными категориями, что приводит к 4500 документов настройки фасетов, запрос по идентификатору категории занимает около 16 секунд при запросе фасетов и около 0,05 секунд при отсутствии запроса фасетов. Протестированная категория содержит около 6 тыс. продуктов, 23 различных фасетов и 2 тыс. различных комбинаций имя-диапазон фасетов. После просмотра кода в FacedQuireRunner появляется запрос фасетов, который приведет к запросу Lucene для каждой комбинации имя-значение фасета, чтобы получить счетчики, а также запрос для каждого имени фасета, чтобы получить термины. Одна из проблем реализации заключается в том, что она извлекает все отдельные термины для данного имени аспекта независимо от запроса, что в большинстве случаев значительно уменьшает количество терминов для аспекта и, следовательно, количество запросов Lucene. Одним из способов повышения производительности здесь было бы сохранение вычисленного результирующего набора MapReduce (как показано выше) для каждого документа настройки фасета, который затем можно было бы запросить, чтобы получить все отдельные термины при дальнейшей фильтрации по фасетам. Однако общая производительность может быть слишком медленной.

5
задан Community 23 May 2017 в 10:34
поделиться