...
[16:20:31 CST(-0600)] <EricDalquist> yup
[16:21:56 CST(-0600)] <cwaymire> hey. ok so this aggregation table has (in addition to the normal date, time, group, interval, etc) a search term column and a count column. I have an aggregation key defined that extends from BaseAggregationKeyImpl and just adds in a getter for the searchTerm and adjusts the hashcode/equals methods appropriately.
[16:22:21 CST(-0600)] <cwaymire> i'm seeing a situation where sometimes it properly creates a new row given a new search term, and sometimes it increments the count of an existing row even though its a unique search term
[16:22:31 CST(-0600)] <cwaymire> would that be an issue with the key?
[16:22:48 CST(-0600)] <EricDalquist> hrm
[16:23:08 CST(-0600)] <cwaymire> not sure exactly how the key is used underneath
[16:23:23 CST(-0600)] <EricDalquist> it could be ... you'd need to make sure the DAO is consistently creating the key based on the event
[16:23:38 CST(-0600)] <EricDalquist> if you want to push this out on a branch I could potentially take a look at it tonight
[16:24:00 CST(-0600)] <cwaymire> I put a debug statement in and I watch it call the createAggregationKey for each interval and have confirmed the key is correct
[16:24:07 CST(-0600)] <cwaymire> yet the update was wrong
[16:24:32 CST(-0600)] <cwaymire> i'll push it out to my github repos
[16:26:06 CST(-0600)] <EricDalquist> ok
[16:26:09 CST(-0600)] <EricDalquist> thanks
[16:27:42 CST(-0600)] <cwaymire> https://github.com/waymirec/uPortal/commits/NOJIRA is where it will live