Folks,
I have just committed all the changes for this. The changes are quite
extensive due to the fact that the primary key for the PERSON table had
to be changed. The changes are both to the webapp and workload
directories. I would really appreciate it if others can test this out as
well.
Thanks
Shanti
Akara Sucharitakul wrote:
In kind of a hurry, I put together a fix for OLIO-40 for the Java kit.
There are a couple of choices made without the best of confidence.
Without thorough testing, we'll never know we're dealing with the
right choice.
I'm trying to conceptually stick with the original idea of processing
the file uploads without saving to any file. I think it is a great
idea, but presents a good amount of challenges. So we will insert a
record with whatever we have in the request before the first uploaded
file - in one transaction, in order to obtain the key (user or event
id). Then we save the image into place and process the thumbnail at
the same time. The complete record will be written in an update,
complete with image locations. The address will be created and linked
at update time (after the initial insert) just to be sure all the
address information has arrived, and also to be sure we don't create
the address twice and call the geocoder twice.
If this strategy doesn't work, the alternative is to do the address
and geocoder in the first create. We need to make sure the sequence
the field arrives is so that the images and literature arrive last.
The update needs to be narrowed down to just the image file (for which
we don't have the file name at create) in the update - just like how
we do it in php.
Since I'm not going to be available for a week, I have to leave the
patch up here for review and comments. Please feel free to test it out
if you have the time. Let me know any fixes you make. I'll resume
testing after I'm back. Again, any comments about this initial code as
well as the strategy taken is most welcome.
Regards,
-Akara
