Предыдущий ответ не совсем правильно - вы должны быть осторожны с триггерами ... они фактически перезапишут любое значение по умолчанию, которое вы передадите, если будете использовать, как в этом примере. Все будет работать нормально, если первичный ключ не установлен, но если вы передадите его с помощью INSERT, он будет уничтожен новым случайным ключом триггером.
Для правильной работы необходимо проверить, имеет ли поле значение, прежде чем назначать новое, следующим образом:
DELIMITER ;;
CREATE TRIGGER `sometrigger`
BEFORE INSERT ON `sometable`
FOR EACH ROW
BEGIN
IF ASCII(NEW.uuid) = 0 THEN
SET NEW.uuid = UNHEX(REPLACE(UUID(),'-',''));
END IF;
SET @last_uuid = NEW.uuid;
END
;;
Я использую ASCII()
, чтобы проверить новое значение поля, так как ASCII()
вернет 0 для пустой строки, если данные представлены в текстовом или двоичном формате (а пустая строка является значением по умолчанию для полей без набора по умолчанию) ). Я также использую binary (16) для хранения своих UUID для наиболее эффективного пространства хранения и скорости запросов ... если вы не хотите справляться со сложностями двоичных полей, тогда вы можете просто использовать UUID()
вместо UNHEX(REPLACE(UUID(),'-',''))
с полем char (36) .