I have a new installation of ContentBox (created during the Developer Week) and I tried to delete the existing “First Entry” from the Blog and got the attached error. I checked the ColdFusion Error log and it showed the following error:
ERROR coldbox.system.Bootstrap Error: An exception occurred when committing the transaction. The root cause of this exception was: coldfusion.orm.hibernate.HibernateSessionException: deleted object would be re-saved by cascade (remove deleted object from associations): [cbStats#3]. ExtraInfo: <?xml version="1.0" encoding="UTF-8"?><transactiontag$transactioncommitexception type=“coldfusion.tagext.sql.TransactionTag$TransactionCommitException”></transactiontag$transactioncommitexception>
ContentBox is v3.0.0+00572. If I remember correctly, I downloaded the zip file. I did not create it using CommandBox.
I am running on Adobe ColdFusion 2016 and IIS on Windows 8.1 using full rewrites via the IIS URL Rewrite extension. My back end is SQL Server 2012 Developer Edition.
Any help fixing this would be appreciated. I can provide the error log from ContentBox if that would help.
Sorry to be the bearer of bad news but I installed the bleeding edge version of contentbox, restarted CF 2016 and still got the same error trying to delete the Blog entry.
I did both an upgrade install over top of my current ContentBox installation and as a clean install in a separate folder. Same results either way.
After a little debugging I noticed that it appears to be getting this error when it tries to delete the stats for the entry, before deleting the entry (see the partial stack trace below). Line 241 in the ContentService.cfc is: delete( arguments.content.getStats() );
I went one further. I created another new “test” blog entry. Visited it on the site. A new cb_stats record was created for it. I then tried to delete it and boom! Same error. I then manually deleted the new stats record from the cb_stats table and then the test entry was successfully deleted.
Ok, I was able to reproduce on ACF2016. For some reason I could not replicate on Lucee.
Anyways, I streamlined the model and fix has been committd. Give it about 30 minutes for it to build and you can install the be again via CommandBox: box install contentbox@be
BTW, When I tried to re-install contentbox@be I still got build 601 (as it grabbed it from my artifact cache). I then cleared the contenbox “3.1.0-snapshot” artifact from my local cache and tried again and this time I got the 604 build. Should commandbox check forgebox to see if there is an updated version of the artifact and re-download if there is?
CommandBox will not download a package again once it has it in the local artifacts cache. There is currently no way to flag a package as “don’t cache” but perhaps there should be a special rule for a pre-release identifier of “snapshot”. When it comes to alpha, beta, or RC releases you usually bump them every time you want to make another release as beta.1, beta.2, beta.3, etc. However, Snapshots are usually just the latest version.
I’ll put in a ticket for CommandBox to consider never caching versions if their pre-release identifier is “snapshot”.
