Just to let others know that I'm debugging/fixing this patch now.
I currently have the existing file opens working and now am moving on to
testing the uploads.
Shanti
On 10/19/09 15:49, 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
