[09:07:12 CST(-0600)] <Arvids> EricDalquist, is there anything in hibernate 4.1.1 that requires postpone the release of uPortal 4.0.4?
[09:31:59 CST(-0600)] <EricDalquist> well there are bugs in 4.1.0 
[09:32:04 CST(-0600)] <EricDalquist> so we can't use 4.1
[09:32:50 CST(-0600)] <EricDalquist> we could just cut 4.0.4 on 4.0.0
[09:33:00 CST(-0600)] <EricDalquist> and wait until 4.0.5 to get the naturalId stuff
[09:41:13 CST(-0600)] <Arvids> ok, I was looking at 4.1.1 release plan and couldn´t find whether any of those changes are blockers or not
[09:41:43 CST(-0600)] <EricDalquist> yeah, sadly my naturalId patch got in right before 4.1.0 was cut
[09:41:50 CST(-0600)] <EricDalquist> so I didn't get a chance to test the snapshot in uPortal
[09:41:55 CST(-0600)] <EricDalquist> and once I did a found a bunch of minor bugs
[09:42:09 CST(-0600)] <EricDalquist> https://hibernate.onjira.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=resolution+%3D+Unresolved+AND+reporter+%3D+currentUser%28%29
[09:42:32 CST(-0600)] <EricDalquist> there are pull requests waiting for all six of those issues
[09:42:43 CST(-0600)] <EricDalquist> and I've tested the fixed build and it all works as expected
[09:44:15 CST(-0600)] <Arvids> ok, sounds reasonable
[09:44:54 CST(-0600)] <EricDalquist> the only down-side I've seen to the naturalId stuff is that unlike the query cache naturalId queries for entities that don't exist are not cached
[09:45:03 CST(-0600)] <EricDalquist> there are a few places in uPortal where this is an issue
[09:45:13 CST(-0600)] <EricDalquist> but in the hibernate 4.1 branch I have I think I have that addressed
[09:46:12 CST(-0600)] <Arvids> in fact, that´s a big issue 
[09:46:24 CST(-0600)] <Arvids> btw, can you take a look at this: https://gist.github.com/1893367 ?
[09:46:51 CST(-0600)] <Arvids> i´m trying to figure out what´s causing this (I´m using the ´evil´ MSSQL)
[09:47:14 CST(-0600)] <EricDalquist> from my testing after your portlet entity fix the only other entity type that causes problems is stylesheet user preferences
[09:47:18 CST(-0600)] <EricDalquist> and I think I have a fix for that
[09:47:20 CST(-0600)] <EricDalquist> hrm
[09:47:30 CST(-0600)] <EricDalquist> so we are using JodaTime for all the stats stuff
[09:47:37 CST(-0600)] <EricDalquist> which has custom usertypes
[09:47:45 CST(-0600)] <Arvids> yeah, i´m starting to dig into that stuff
[09:47:59 CST(-0600)] <EricDalquist> does mssql have a special operator to compare dates?
[09:49:10 CST(-0600)] <Arvids> strange is that this message doesn´t make sense, because mssql column type is time(7) and it looks like parameter is also being set as time... strange
[09:50:13 CST(-0600)] <EricDalquist> in a SQL client
[09:50:18 CST(-0600)] <EricDalquist> can you execute that same query?
[09:50:24 CST(-0600)] <EricDalquist> and will it work with the =?
[09:50:42 CST(-0600)] <EricDalquist> or is it saying that it thinks you're trying to do "date == datetime"
[09:50:47 CST(-0600)] <EricDalquist> and that isn't ok
[09:51:02 CST(-0600)] <Arvids> yes, i can
[09:51:59 CST(-0600)] <Arvids> ... but maybe mssql server manager does some kind of magick behind the scene
[09:52:34 CST(-0600)] <EricDalquist> try using SquirellSQL
[09:52:50 CST(-0600)] <EricDalquist> I like it more for a SQL client since it is 100% Java & JDBC
[09:53:00 CST(-0600)] <Arvids>
[09:53:02 CST(-0600)] <EricDalquist> makes it truer for testing than DB specific SQL clients
[09:53:21 CST(-0600)] <EricDalquist> also, way lighter-weight than DB specific clients
[09:53:41 CST(-0600)] <EricDalquist> The only other thing I can think to check would be to set a breakpoint at:
[09:53:41 CST(-0600)] <EricDalquist> TRACE [uPortal-TaskExecutor-8] Feb/23 17:15:44,674 sql.BasicBinder.[] - binding parameter [1] as [TIME] - 13:57:00
[09:53:49 CST(-0600)] <EricDalquist> and see what the actual Object type being set is
[09:54:32 CST(-0600)] <Arvids> yes, makes sense
[09:57:42 CST(-0600)] <Arvids> squirrel executes witouth any problems
[09:59:05 CST(-0600)] <EricDalquist> hrm
[09:59:46 CST(-0600)] <Arvids> i´ll try debugging
[10:00:19 CST(-0600)] <Arvids> it looks like localtime is being converted to java.sql.Time
[10:00:26 CST(-0600)] <Arvids> i woner why it isn´t working
[10:00:45 CST(-0600)] <EricDalquist> do you know what dialect is being used?
[10:01:14 CST(-0600)] <EricDalquist> it looks like SQLServer2008Dialect is the first sqlserver dialect that does
[10:01:14 CST(-0600)] <EricDalquist> registerColumnType( Types.DATE, "date" );
[10:01:14 CST(-0600)] <EricDalquist> registerColumnType( Types.TIME, "time" );
[10:01:14 CST(-0600)] <EricDalquist> registerColumnType( Types.TIMESTAMP, "datetime2" );
[10:01:35 CST(-0600)] <EricDalquist> all previous did:
[10:01:36 CST(-0600)] <EricDalquist> registerColumnType( Types.DATE, "datetime" );
[10:01:36 CST(-0600)] <EricDalquist> registerColumnType( Types.TIME, "datetime" );
[10:01:36 CST(-0600)] <EricDalquist> registerColumnType( Types.TIMESTAMP, "datetime" );
[10:01:43 CST(-0600)] <Arvids> ahhh... maybe i have to explicitly set dialect
[10:01:57 CST(-0600)] <EricDalquist> yeah
[10:02:06 CST(-0600)] <EricDalquist> or add more logic to the uPortal dialect resolver
[10:02:25 CST(-0600)] <Arvids> heh... that might be the solution
[10:02:27 CST(-0600)] <EricDalquist> org.jasig.portal.utils.PortalDialectResolver
[10:02:35 CST(-0600)] <Arvids> i´ll modify PortalDialectResolver