While I still don’t actively work on DBX anymore, I did have occasion to work on a client using SQLServer and took the opportunity to add/enhance a few things that were annoying me:
- added a filter for the left-hand TOC which does simple string-matching to filter objects
- enhanced object cross-linking in various detail views; e.g., when viewing FK relationships, you can now click-and-go to the objects listed
Download from dbx.riaforge.org.
On a different note, James Moberg was kind enough to alert me to an incompatibility with Microsoft’s SQLJDBC driver under Adobe ColdFusion. It works fine with the default Adobe JDBC connector, but the MS SQLJDBC driver does not support the sqlvariant datatype, and a number of queries under the DBX hood make use of that datatype. I’ll be addressing it at some point in the future, but for now just note that if you wish to use DBX, you’ll need to use the default JDBC connector. This should be true of Lucee as well.
I’ve been using ColdSpring 1.2 for years now. Yes, it’s a dead project, and yes I did try to migrate to 2.0 a few years back but there were issues that prevented it at the time (is that version dead now too?), but I always liked ColdSpring and its pretty entrenched in a number of apps I’ve developed and there’s never any time or desire from the powers on high to retool it for Wirebox or DI/1.
ColdSpring has always had a real downside for me, though: the sheer amount of time it adds to app reinitialization. In the case of an eCommerce site I’m working on, the app reinit time was a whopping 274 seconds on a very beefy server (8-core, 32GB ram, SSDs). The length of reinit time became critically painful when we moved the site behind CloudFlare which implements a very strict and unconfigurable request timeout of 100 seconds (the fact this is unconfigurable for paying customers to me seems absurd, but there it is). The net effect of this restriction was that it was impossible to know when, or if, the app had successfully reinitialized, as CloudFlare throws in a handy ‘the page didn’t respond in time, oh well’ error. I knew the reinit sluggishness was in ColdSpring, since I had isolated ColdSpring functionality as the root cause in another app, but I had never ended up digging too deeply since I guess I just felt it was a burden to be borne for the sake of using an IOC framework (this is several years ago). But faced with very real and unalterable request timeout restrictions I now had no choice but to give it another go.
And……succeeded. The culprit? AOP. I’ve always used the aspect oriented programming feature of ColdSpring to implement page-level security. Essentially, in my apps all page urls are aliases stored in a db, resolved on demand and routed to the appropriate controller. Each of these page aliases has optional security role requirements which must be evaluated for the current user to determine whether they can access the url or not. This is an ideal situation for AOP. And this was the ONLY thing I was using AOP for. Unfortunately for my ideal use of AOP, I had narrowed down the lag to ColdSpring’s AOP handling for my controllers, and after removing the app’s reliance on AOP and moving the relevant security-evaluation code into the single component actually handling request routing, reinit time went from 4 minutes down to 12 seconds. 12 seconds. From 4 minutes. Blech.
I still like ColdSpring 1.2 and would use it again, even as old and dead as it is, but if I do I won’t be using ColdSpring’s AOP features. The cost to any non-trivial app is just too high at init time.
Had a recent battle with moving over a routine from ACF 9 to Lucee where we had a Flash embed which would send binary data (a generated image) to a CF file to be processed and saved. The routine worked fine under CF9 but failed under Lucee (and Railo).
What appeared to be happening is that Lucee/Railo was forcibly converting content sent as application/octet-stream to string when it should have been binary. You can easily see where this is happening in the Lucee source code, but suffice it to say that while it may be ‘right’ for certain circumstances, it seems pretty wrong to me. There had been bug reports posted and a justification provided for the current behavior, but regardless there is a workaround until/if it gets changed in Lucee.
Where you would normally use getHTTPRequestData().content to get at the binary request body, instead use getPageContext().getRequest().getOriginalRequest().getInputStream() . This gets at the request body from the original unmodified request before Lucee gets it’s hands on it by way of getHTTPRequestData() and avoids the manner in which Lucee abstracts the data in such a way as to mangle binary data.
Needed a function to de-duplicate string lists, so I modified a similar UDF from SQLAuthority. That original UDF didn’t preserve the position of list elements or handle case sensitive comparisons, and I wasn’t too keen on the variable naming. Anyway, my version is below and let’s you specify the list delimiter as well as control case sensitivity, in addition to preserving the original sequence of list items.
There are tons of people with the same issue (sound stutters, delays, etc.) on Windows 7 with Realtek on-board sound cards and I have found that simply disabling Windows Defender completely solved my problem.