Материализованный вид не обновляется - PullRequest
0 голосов
/ 08 ноября 2018

У меня есть материализованное представление, которое в основном отслеживает все ваучеры, использованные при оформлении заказа, так что я могу отслеживать, сколько было использовано, сколько осталось и т. Д. Я только что заметил, что материализованное представление не обновится. показывает следующее:

enter image description here

Где left очевидно уменьшается по мере использования ваучеров (тип ваучера и ваучеры, используемые вместе с идентификатором пользователя, который его использовал, находятся в разных таблицах). Однако он обнаружил, что один ваучер использовался, но что касается двух других, которые я использовал при тестировании, он не заберет их из таблицы, где хранятся использованные ваучеры, и обновит MV.

Вот часть миграции, которую я сейчас выполняю для создания MV:

exports.up = function(knex, Promise) {
  return knex.schema
  .raw(`
  CREATE MATERIALIZED VIEW mv_vouchers as
  SELECT v.voucher_id, v.quantity, COUNT(ov.voucher_id) AS "used", v.quantity - COUNT(ov.voucher_id) AS "left"
  FROM public.vouchers v LEFT OUTER JOIN
       public.order_vouchers ov
       ON v.voucher_id = ov.voucher_id
  GROUP BY v.voucher_id, v.quantity;
  `);
};

У меня такое ощущение, что я неправильно использовал материализованное представление и что он выполнил запрос в процессе миграции только один раз (когда я изначально реализовал mv).

EDIT

Для дополнительной информации вот еще две таблицы, которые у меня есть:

ваучеры:

enter image description here

order_vouchers:

enter image description here

Ответы [ 2 ]

0 голосов
/ 08 ноября 2018

Просто подумал, что бы добавить быстрое решение к этому:

exports.up = function(knex, Promise) {
  return knex.schema
  .raw(`
  CREATE MATERIALIZED VIEW mv_vouchers as
  SELECT v.voucher_id, v.quantity, COUNT(ov.voucher_id) AS "used", v.quantity - COUNT(ov.voucher_id) AS "left"
  FROM public.vouchers v LEFT OUTER JOIN
       public.order_vouchers ov
       ON v.voucher_id = ov.voucher_id
  GROUP BY v.voucher_id, v.quantity;
  `)
  .raw(`
      CREATE FUNCTION refresh_mv_vouchers() RETURNS trigger LANGUAGE plpgsql AS $$
        BEGIN
          REFRESH MATERIALIZED VIEW CONCURRENTLY mv_vouchers;
          RETURN null;
        END $$;
    `)
    .raw(`
      CREATE TRIGGER refresh_mv_vouchers
        AFTER insert OR update OR delete OR truncate
        ON order_vouchers
        EXECUTE PROCEDURE refresh_mv_vouchers();
    `);
};

exports.down = function(knex, Promise) {
  return knex.schema
    .raw('DROP MATERIALIZED VIEW mv_vouchers')
    .raw('DROP TRIGGER refresh_mv_vouchers ON order_vouchers')
    .raw('DROP FUNCTION refresh_mv_vouchers()');
};

Был намного более прямолинеен, чем я первоначально думал, используя:

BEGIN
          REFRESH MATERIALIZED VIEW CONCURRENTLY mv_vouchers; ...
0 голосов
/ 08 ноября 2018

MV в основном является таблицей, за исключением того, что он также запоминает, какой запрос он должен выполнить, чтобы обновить (фактически заменить) его содержимое.

Я думаю, что у Postgres нет параметра для автоматического обновленияMV , либо живой, либо периодически.

Данные запрашиваются и сохраняются при создании представления, кроме случаев, когда вы указываете WITH NO DATA, и в этом случае создается пустое.

Затем можно (повторно) заполнить представление по требованию.позвонив по номеру REFRESH MATERIALIZED VIEW.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...