All work
There's nothing matching your search
Redesign types + introduce TypeRegistry & TypeResolver
Description
is a fix for
required for
Details
Assignee
Steve EbersoleSteve EbersoleReporter
Steve EbersoleSteve EbersoleTime tracking
78h loggedComponents
Fix versions
Priority
Major
Details
Details
Assignee
Reporter
Time tracking
Components
Fix versions
Priority
Activity
Jason Perrone October 5, 2012 at 5:41 PM
Ok, i can do that. Thanks
Steve Ebersole October 5, 2012 at 5:37 PM
Lots of places reference this. We obviously missed some. Report them in a Jira as you find them. Contributions welcome.
Jason Perrone October 5, 2012 at 5:24 PM
It doesn't seem that the documentation is really updated for this change. For instance, in the 4.1 developer guide online, in the scalar native SQL queries section, it still shows referring to Hibernate types as Hibernate.LONG and Hibernate.CALENDAR. If there's going to be a change like this, shouldn't the docs be updated?
Tyler Southwick December 21, 2010 at 8:11 PM
This doesn't seem to be backwards compatible with previous versions of hibernate (it would seem since it is 3.x.x it should be). We have some older libraries that defined their own EnumUserType and was using TypeFactory.basic which is no longer there. What should I do to make these work with hibernate 3.6?
Former user September 1, 2010 at 4:05 PM
Does this redesign solve [this:HHH-468] long standing issue?
Work in progress. The general idea is to have 3 levels of types:
1) What I am tentatively calling a StaticType. These are basic mappings between standard java types and basic sql types. They require no access to a Session nor SessionFactory to fulfill their contracts.
2) Scoped. This is mainly the current Type contract, except that these will be explicitly scoped to a TypeRegistry (which is part of the Configuration and SessionFactory). Users can provide overrides of these.
3) User types. Again, mainly the current user types contracts.