DataPortalEvent Type

DataPortalEvent Type

Old forum URL: forums.lhotka.net/forums/t/792.aspx


DeanG posted on Wednesday, August 02, 2006

Rocky / All

I have been working w/ 2.01 of the framework creating business objects based on an existing web app which has a rather 'unique' database row locking mechanism. Due to this, I have the need to mark the object 'dirty' if the lock was achieved so that a call back to the database can remove the lock. Since I have created a base class that inherits from BusinessBase that the rest of my business object will descend from, this would be the appropriate place to do this, and I expect I would do this in an override of DataPortal_OnDataPortalInvokeComplete. I only want to do this if the event calling this method is the fetch. (I can also forsee needing to do other work for some of the other methods such as save.) Seems the DataPortalEventArg should include the method type (Fetch, Save, etc). Has there been any consideration to doing this, or am I going about this the wrong way. If this is an appropriate direction but is not implemented, I'd be more than happy to make the change and provide it.

Thanks in advance,

Dean.

 

xal replied on Wednesday, August 02, 2006

I don't think this is a good approach, because if the user closes the app without saving, the record would be locked forever...

That said, you could simply call MarkDirty() at the end of your DataPortal_Fetch method and that would be it...

Andrés

DeanG replied on Thursday, August 03, 2006

Andres,

That is the intent, to call MarkDirty at the end of the Fetch. What I do not want to do is have to code that same call in each business object, rather I would like to ensure it is called by delegating it to the base class of my business objects. If the record is not marked dirty, then calling update would have no effect as there are no actual changes to the object, but I need to have it called so at least the lock would be removed. 

Since we have the before and after events, I think it makes sense to include notification of what triggered the event.

True, if the user never calls delete (which frees the lock) or update (which saves any changes AND frees the lock) the lock would remain... until our database job that periodically scans for records that are locked but inactive removes said locks. This is the next thing I am intending to address.

Thanks,

Dean

RockfordLhotka replied on Thursday, August 03, 2006

Dean, you are right - it would be better to have more information passed to the pre and post data portal event handlers. I don't know if I'll be able to get that into 2.1 or not, but it is an enhancement that I want to do at some point.

Copyright (c) Marimer LLC