FileUpload : timing of copying from temporary file to final file name is off? about serenity HOT 4 CLOSED

The FileUploadBehavior updates the name of the file in here https://github.com/serenity-is/Serenity/blob/master/src/Serenity.Net.Web/Upload/FileUploadBehavior.cs#L342

And the triggered here
https://github.com/serenity-is/Serenity/blob/master/src/Serenity.Net.Services/RequestHandlers/Save/SaveRequestHandler.cs#L59

You should call your base function to trigger them, then you can access the latest file name in your save handler.

If you try to use this final name in the behavior, the call order will be effect the result. The problem is here, your behaviors should not be depended on other behavior data. There is no order functionality. Anyway, if it is a strict requirement, you can override the "GetBehaviors" in your SaveHandler and order them as required.

from serenity.

OK thank you. But @VictorTomaili FWIW I wasn't "using the final name in the behavior". I was using it in a SQL trigger. I don't think this is the same thing. I understand that name change is being "triggered" in the AfterSave but was suggesting that maybe AfterSave was not the right place if a SQL trigger, which sits outside Serenity, was seeing the temporary name.

Also please note that my SQL trigger was after insert, not instead of insert.

There is no order functionality.

Yes, there is, in the sense that AfterSave is... after Save .

from serenity.

The SQL trigger is not expected in file update behavior. Serenity is not check for whether there is any trigger or not in SQL database. You have some business on your database side, and serenity is not responsible for that. You can move this business into your code, or you can check for the final state of the value with some extra business. Creating a new behavior for uploading files is also possible.

from serenity.

@VictorTomaili of course Serenity isn't "responsible" for a trigger.

My point was exactly that a trigger is outside of Serenity, so I was surprised that it could see a temporary value.

If you are saying that all of this activity on the Serenity side up to and including the rename of the file and whatever else might occur during AfterSave, is part of a unit of work -- whether because the row is locked or a transaction is underway or some other definition -- from your point of view, and that nothing else from the outside should be touching the row until it is complete, then I understand your position.

If a transaction is underway at the time of AfterSave, it is really weird that the trigger sees the temporary value, in fact (remembering that it is an after, not instead of trigger.)

Are you absolutely sure that no other activity outside the Serenity process, beyond a trigger, couldn't accidentally read the temporary value from the database row, during a brief time period?

I want to understand how this works. If you are not absolutely sure, then I want to take care of it on my end, certainly not make Serenity "responsible" for it, but I also suggest that the docs reflect this behavior in some way.

Thank you in advance for understanding my position, and for a thoughtful response.

from serenity.