I needed to write a query that would output a list of entities, with a subselect containing all of it’s related entities (could be multiple) in a comma separated list. This was for a one time report, so performance was not a concern, just simplicity. This post was had a solution that dominated my task, check it out!
If you are experiencing this error while (especially while using ORM in CF9), I recommend taking at look at Ray Camden’s post to resolve the issue. I was absolutely destroying outlook by doing full error dumps and sending emails to myself!
With their recent update, it appears they have replaced the links that used to be at the top of your inbox (all, none, read, unread, etc) that you could click to check that subset of emails. The new convention is pretty neat. Now, the “check all” box for your inbox has been replaced with a sort of hybrid checkbox/select. You can check it and as you would expect it, would check all emails below it. Otherwise you can click the select arrow to see a list of those same commonly used subsets that used to appear at the top of your inbox. Clicking one of these options will select the corresponding subset of emails, just like the links used to.
I personally think this is a really neat idea for any criteria based list UI that has a subset of criteria that is more commonly used than most. I always liked what they were trying to accomplish by providing a shortcut to commonly used criteria, but I like this implementation better than the last. Looks cleaner.
Another new addition (at least I believe it is new) that I find noteworthy is also somewhat related to the check all functionality. In the past, check all was limited to only the records visible on your page. Any emails beyond that you, would have to click to that page and hit check all for those as well. I think this is a frustrating scenario that many developers have encountered at some point. When someone truly needs to check all, not just what is visible on the page, often times the solution I have went with is to offer a “View All” option in the pagination. Problem here is you are sacrificing the performance benefit of loading up only a single page of records. With some larger result sets, this might literally not even be an option for you.
Google has implemented a UI here that allows the user both options at the same time. Checking the check all box will check the visible results on the page for starters, but you are then also greeted with a linked message asking if you would like to check ALL results, even beyond that of what is on the page. This offers each solution, but with neither do they sacrifice the performance of paginating results.
I’d like to see them do one thing to take it a bit further. Right now, the link appears to only be presented when you check all options. I don’t see any reason why you shouldn’t have a link with the same option for the options available in the select for unread, read, etc. I want to be able to select all unread messages, and have it present me with a link that tells me the count of unread messages throughout the inbox and asks me whether I’d like to select those too.
Overall though, I give a thumbs up to the new enhancements.
DISCLAIMER: This is misinterpretation is probably more attributed to this being one of my first experiences with ORM and my first experience with Hibernate. I imagine those experienced with Hibernate are all very aware of this.
When I started my ColdFusion ORM project, I learned quickly that the recommendation seems to be to set FlushAtRequestEnd to false. For those not familiar with this, it is defaulted to true, and when true, will ensure that each and every change made to an object will be persisted to the database when the request completes. Setting this to false ensures that you have the control to determine when this flush occurs by calling ORMFlush() when you are ready to persist the changes. Or does it?
I had a scenario where there my application used the function below for both adding and updating payer objects.
Well at first I forgot to place my ORMFlush() call after the EntitySave. No biggie, nothing should be saving though because of this, right? Wrong, updates were not coming through, but I found that inserts were actually working despite the flush never taking place. Long story short, after spending over an hour trying to debug the issue, I went back to dig into the documentation more and low and behold, I found something I must have skipped over before.
"The only exception to this is that objects with nativeId generation are inserted immediately when the object is saved."
My database is using identity insert for the primary key generation, which I believe qualifies as "nativeID generation". Now that I know this is how it works it makes perfect sense, how can it possibly return you an object with a primary key generated by the database without actually saving it to the database? Hopefully this saves someone some time and frustration.
I have been reading up on the pros and cons of INT vs GUID primary keys and have learned quite a bit I wasn't aware of regarding the downsides of GUID when it comes to indexing and performance. One thing I saw a few people suggest was to use an INT as the clustered primary key and then a GUID as a nonclustered key in addition to this. The idea is that you would have the performance benefits of using the INT as the primary key, but still maintain the ability for two way data synchronization across servers.
My question is this. It seems to me that if you one were to use GUID as the primary keys, a tool like SQL Data Compare would be extremely powerful as off the top of my head, I feel like data synchronization would be a breeze. However, if the guid was only a secondary key, and INT was still used for primary keys and foreign key reletionships, then I would think that an automated tool like this would not be effective. My assumption is the GUID would only exist on the original record, not on related records, therefore there would be conflicting primary/foreign keys causing confusion to a data comparison tool. Yes, with stored procedures these secondary GUID keys would make it possible to perform two way synchronization, but don't see it as offering the same level of ease that using the GUID as a primary would.
Anyone have experience with this concept and want to chime in? Maybe I am misinterpreting the way this has been described and someone can steer me in the right direction.
This weekend I setup my local environment for developing Android applications and did a Hello World tutorial. I'm tired of sitting around complaining that the app I want isn't there. I'm just going to start writing them! Hopefully it doesn't take me too long to get rolling.
When I take the time to sit and write code samples to prove that jQuery's live method does not respond to the native load event, and then my test cases prove I was wrong all along. Guess I will have to revisit the code where I ended up using a custom event called "loaded" because I believed this to be the case. Fail, but I guess it is never a bad thing to figure something out even if it proves yourself wrong.
Pretty awesome tool to build Visual Studio themes via a simple user interface.
Most ColdFusion developers have probably realized at some point that ListToArray ignores empty values between delimiters altogether. What I mean is that "a,,,b,c,d" would return an array with only 4 items in it, rather than 6 items with two of them being empty. This has been frustrating to say the least. ColdFusion 8 to the rescue, ListToArray now has a third arguments "includeEmptyField" that defaults to false, but if true will not ignore empty values. See the following code for an example:
The above code results in the following output. Nothing unexpected here, but a welcome addition nonetheless.
So I was working on an ajax request that reloads a select based on it's dependency to the selection made in an adjacent select, and noticed that all of a sudden, the javascript helper I was using was no longer working. This came as a surprise as this had been stable for quite some time and the scenario I was using it for seemed identical to those I have used it for in the past. After spending some time looking into it, I realized the problem. My function that returned the results to reload the select in this scenario was using a Query of Query, where in the past I had always been returning a Query result straight from the database. Upon taking a peak at the actual JSON object returned from serializeJSON() and realized that the keys for the data object returned from a normal Query would always return in all caps, and the JavaScript followed this assumption. The Query of Query actually returned the keys in the exact case used for the select in the query itself. Look at this example to see what I mean: