Saving child objects when parent is incomplete in web application
I am trying to establish a best practice for handling creation of child objects when the parent is incomplete or does not yet exist in the web application. I want to handle this in a stateless manner, so there is no memory in the objects.
For example, let's say we have a bug tracking application.
A Bug has a title and description (both required) and any number of attachments. Thus, "Error" is the parent of the "Attachments" list of children.
So, you present a page with title input, description input and file input to add attachment. Then people add attachments, but we haven't created a parent bug yet.
How do you handle saving added attachments?
Obviously, we have to keep track of the attachments that have been added, but at this point we have not saved the parent "Error" object to bind "Attachment" to.
source to share
Create an incomplete error and define a process for handling the incompleteness. (Wait X minutes / hours / days, then delete it / email someone / accept it as it is.) Even without a title or description, knowing there was a problem and the information in the app is potentially useful. The attachment can include a full description, but the user simply posts it somewhere other than your presence. Or it may only contain scattered data points that are meaningless on their own, but may corroborate another user report.
source to share
I usually just create a Bug object and its Attachment child within the same HTTP response after the user submits the form.
If you are reading correctly, user input consists of a single form with the above fields for title, description, and an attached error file. After the user fills in these fields (including choosing a file to upload), then click Submit, your application will simultaneously receive all three of these pieces of data as POST variables in the HTTP request. (The attachment is another bit of POST data, as described in RFC 1867. )
From the end of your application, depending on which structure you are using, you will probably be given a filename pointing to the location of the downloaded file in some suitable temporary directory. For example, using the Perl CGI module, you can:
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";
to get the name of the uploaded file (the file data submitted through the form by your user is automatically saved in a temporary file for your convenience) along with its metadata. Since you access both the text fields and the file attachment at the same time, you can create your Bug and Attachment objects in any order without requiring any incomplete data in the HTTP responses.
Or am I misunderstanding you here?
source to share
In this case, I would like to consider storing attachments in some kind of temporary storage, be it session state, a temporary directory on the filesystem, or perhaps a database. Once the error is saved, I will then copy the applications to their actual location.
Careful with the session, though if you allow them to download large attachments you may be causing memory issues depending on your environment.
One approach I've seen before is as soon as the user opens a new error form, a new error will be generated in your database. This may or may not be good depending on your application. If you collect data from a user, for example, this is useful as you gain some intelligence even if they cannot enter data and leave your site. You still know that they started the process and whatever you put together as a user agent, etc.
source to share