Сохранение дочерних объектов, когда родительский объект неполон в веб-приложении

Question

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

Например, скажем, у нас есть приложение для отслеживания ошибок.

Ошибка имеет заголовок и описание (оба обязательны) и любое количество вложений. Таким образом, «Ошибка» является родительским объектом со списком дочерних элементов «Вложения».

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

Как вы справляетесь с сохранением добавленных вложений?

Очевидно, что мы должны отслеживать добавленные вложения, но на данный момент мы не сохранили родительский объект «Ошибка», чтобы прикрепить «Приложение».

Answer 1

Создайте неполную ошибку и определите процесс обработки неполной информации. (Подождите X минут / часов / дней, затем удалите его / отправьте кому-нибудь по электронной почте / примите его как есть.) Даже без заголовка или описания, зная, что возникла проблема, и информация в приложении потенциально полезна. Вложение может включать в себя полное описание, но пользователь просто поместил его где-то, кроме того, что вы посещали. Или он может содержать только отдельные точки данных, которые сами по себе не имеют смысла, но могут подтвердить отчет другого пользователя.

Answer 2

Обычно я бы просто создал объект Bug и его дочерний объект, объект Attachment, в том же HTTP-ответе после того, как пользователь отправил форму.

Если я правильно вас понял, пользовательский ввод состоит из одной формы с вышеупомянутыми полями для названия ошибки, описания и прикрепленного файла. После того, как пользователь заполняет эти поля (включая выбор файла для загрузки), а затем нажимает кнопку Отправить, ваше приложение получает все три этих фрагмента данных одновременно, как переменные POST в HTTP-запросе. (Вложение - это просто еще один бит данных POST, как описано в RFC 1867 .)

Со стороны вашего приложения, в зависимости от того, какую платформу вы используете, вам, вероятно, будет дано имя файла, указывающее на местоположение загруженного файла в некотором подходящем временном каталоге. Например, с помощью модуля Perl CGI вы можете сделать:

use CGI qw(:standard);
my $query = CGI->new;
print "Bug title: " . $query->param("title") . "\n";
print "Description: " . $query->param("description"). "\n";
print "Path to uploaded attachment: " . $query->param("attachment") . "\n";

для получения имени загруженного файла (для удобства данные файла, отправленные пользователем через форму, автоматически сохраняются во временном файле) вместе с его метаданными. Поскольку у вас есть доступ как к текстовым полевым данным, так и к вложенным файлам одновременно, вы можете создавать объекты Bug и Attachment в любом порядке, в котором пожелаете, без необходимости сохранять неполные данные в ответах HTTP.

Или я вас здесь не понимаю?

Answer 3

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

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

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