2014-11-14 1 views
0

У меня возникла следующая проблема. Мне нужно, чтобы строки были вставлены в таблицу «резервирования», чтобы после вставки установить таймер для себя, а затем проверить флажок в этой недавно созданной строке через несколько минут, чтобы увидеть, изменилось ли оно с «ожидающего» на «завершено» (что быть вызваны действием пользователя в промежуточный период) и если все еще «ожидают», чтобы удалить себя из таблицы.Как комбинировать триггер и событие и использовать событие определенного идентификатора строки?

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

Итак, я рассматривал события и триггеры, и я понимаю концепцию для обоих, но то, что я не могу найти, - это способ, по которому триггер передавал id этой строки этому событию, чтобы, когда событие срабатывает, он смотрит только на соответствующую строку, потому что я не хочу, чтобы он заметил * все строки, которые могут быть «ожидающими», поскольку, возможно, недавно созданные «ожидающие» строки другими пользователями для других оговорок за промежуточный период, и я, очевидно, не хочу связываться с ними до тех пор, пока их соответствующие таймеры не пройдут.

Итак ... что я надеюсь на (в псевдо) является ...

/*EVENT*/ 
CREATE EVENT IF NOT EXISTS delete_abandoned_pending_purchase 
ON SCHEDULE AT CURRENT_TIMESTAMP + 5 minutes 
DO 
    delete from tickets where state = 'PENDING' and id = [MY ROW ID] 

, а затем ...

/*trigger*/ 
CREATE TRIGGER remove_if_unused 
AFTER INSERT ON `tickets` FOR EACH ROW 
begin 
[call delete_abandoned_pending_purchase with row_id MY_NEW_ROW_ID] 
end 

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

[EDIT]

reading more about this «Там нет никакого способа передать параметры непосредственно или событий, однако, можно вызвать хранимую процедуру с параметрами внутри события».

Но предложение вызывать хранимую процедуру и передать ей параметр. Тем не менее, моя проблема заключается в том, что я не вижу, как получить * в row.id в случае, чтобы передать хранимую процедуру. Я чувствую, что мне не хватает чего-то очевидного ... как события могут не иметь доступа к определенным идентификаторам строк?

[EDIT EDIT] поэтому, на основе this Я чувствую, что это на самом деле не выполнимо в mySQL ... это облом, а также довольно удивительно. Кажется, это действительно очевидная вещь, которую нужно делать.

Я оставлю вопрос открытым и посмотрю, кто-нибудь совершает кулачную игру с умной альтернативой.

ответ

1

Я бы порекомендовал вам сделать это с помощью скрипта, с меньшей сложностью и большим контролем. Что-то, как показано ниже:

MaxSleep=300 # In seconds SleepTime=MaxSleep 
while (1) { 
    sleep SleepTime; delete from TheTable where reserved = 'pending' and the_timestamp >= Current_Timestamp; SleepTime='mysql 
'select the_timestamp from TheTable where reserved = 'pending' order 
by the_timestamp limit 1" 

    if SleepTime is null then SleepTime= MaxSleep 
} 
+0

Существует ли какой-либо вред в настройке события для того, чтобы делать то же самое (через код) каждый раз, когда добавляется новая строка билета? Мне действительно не нравится представление о том, что в узле есть таймауты (в чем заключается моя бизнес-логика), ожидая многоминутных растяжек. Не слишком ли значительны накладные расходы на mySQL-события? –

+0

Я собираюсь отметить ваш ответ как правильный, хотя я думаю, что предпочитаю метод события, очевидный ответ на мой вопрос заключается в том, что это невозможно в mySQL в это время ... поэтому ваше решение совершенно правдоподобно альтернатива. –

0

Вы можете просто сделать событие, которое проверяет против всей таблицы, должна быть быстрой, если он правильно индексируется, а затем бизнес-логика в БД. Возможно, используйте минуту в качестве проверки, а максимальная ожидающая транзакция - 6 минут, если у вас есть 5-минутный тайм-аут.

CREATE EVENT delete_abandoned_pending_purchase по расписанию в CURRENT_TIMESTAMP + ИНТЕРВАЛ 1 Протокол DO НАЧАТЬ удалить из таблицы, с которой зарезервирован = 'в ожидании' и the_timestamp> = CURRENT_TIMESTAMP; END

Смежные вопросы