Rank: Advanced Member
Groups: Authorized User, Developers Joined: 5/30/2020(UTC) Posts: 125
Thanks: 14 times Was thanked: 3 time(s) in 3 post(s)
|
Thank you Mazhar. I was able to prevent my code from firing on reads when order items weren't dirty. Two questions... 1) Do I have to call ? If so, is it supposed to run before or after my code? 2) fires twice when an order is created, and the OrderItems are dirty each time. I'm assuming it has to do with some other Order relations being updated after the order is saved, or maybe because I'm using a development version and it is updating everything to DEMO, DEMO. On the first pass my OrderItem Ids are all 0. On the second pass they have their identity value. Again, dirty both times. I would expect them to no longer be dirty after the first save. I actually need the OrderItem Id in order to match up with the entry in the inventory system so I was going to use , but wasn't sure how to identify it as a Insert or Update once it is no longer transient and has an id assigned?
|
|
|
|
Rank: Advanced Member
Groups: Authorized User, Developers Joined: 5/30/2020(UTC) Posts: 125
Thanks: 14 times Was thanked: 3 time(s) in 3 post(s)
|
Okay, since the BeforeSave seemed to be firing multiple times, and I needed the ID for new order items anyway, I ended up creating a custom NHibernate listener and implementing the IPostInsertEventListener, IPostUpdateEventListener, and IPostDeleteEventListener interfaces instead. I am able to implement this as part of my plug-in. The downside is that I have to manually register them in the NHibernte.config file within the website using: Code: <listener class="InventoryPlugin.CustomOrmListener, InventoryPlugin" type="post-commit-insert" />
<listener class="InventoryPlugin.CustomOrmListener, InventoryPlugin" type="post-commit-update" />
<listener class="InventoryPlugin.CustomOrmListener, InventoryPlugin" type="post-commit-delete" />
By doing things this way, it appears we have access to all of the NHibernate functionality we need to determine which fields are dirty and can decide whether any inventory updates need to be issued. I believe we've also figured out why BeforeSave was firing multiple times and why the OrderItem was dirty each time... It has to do with the ParentItem property on the OrderItem. After a new OrderItem is created, the ParentItem property is set to the current ID which forces another Update. Makes sense since you do not know what the ID is until after it is saved. We found out that this also causes an additional Update during Delete operations; The ParentItem is set to 0, forcing an Update, then it is Deleted with a second operation. Adding custom dirty property detection will make this a little messier than we'd hoped, but at least should be workable.
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The AbleCommerce Forums uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close