Mike Matrigali wrote: > > > Mike Matrigali wrote: >> This may or may not work, not sure. Here is stuff to be aware of. >> If you do this approach, the store will go ahead and insert and log >> data into the database. For it to work correctly you will >> have to make sure that the resulting error from the limit at least >> aborts the statement which is doing the insert/update. >> >> My guess is that you are going to get some sort of STORE exception >> with the limit exception wrapped below it. I would not be surprised >> if the current store exception is more severe than you want it to >> be as the current code does not expect this error - you may have >> to define a new less severe error in this case. There may be more >> than one exception path. Make sure to test the case where >> the inserted blob exceeds the page size and the case where the >> inserted blob is less than the page size. > > By severity I meant that store may currently raise a transaction or > system level exception. A good test would be to have a multi-statement > transaction and make sure this error does not back out an earlier > statement in the uncommitted transation. >
Hello Mike, Thank you very much for the information. I think I can implement the upper layers of what I plan pretty fast. I'll go ahead and see what happens. I was hoping to avoid making changes in the store, but based on your information I fear that has to done. I appreciate the help on which test scenarios I should write tests for. If you, or anyone else, have more of them, keep'em coming :) I'll report back on my findings as soon as possible, hopefully in a few days. Regards, -- Kristian
