> So that leaves the option of having Types be aware of the session > factory. Which upon further reflection is not as bad as it sounds, > because really there are only a few Type implementations that even need > access to the session factory at all in any of these methods > (sqlTypes(), etc exluded). These would be limited to mainly the > EntityType subclasses, the ComponentType subclasses, and the > CollectionType subclasses. The essential point being that none of the > "primitive"/"simple" types are in this category...
Sounds fair. > The one wrinkle in this approach is the various type factory methods on > the o.h.Hibernate class. These would need to change signature, or go > away. I guess we could limit these changes to be only for those who really needed or would it be better to just get it over with. Still, *alot* of code will break for this :( (luckily it is compile-detectable) Is it worth doing this for sessionfactory scoped types ? Do we get more out of this than sf-controllable bytecode provider ? (I guess some of the issues regarding overriding the default types would also get in here) Could we somehow allow both possibilities for the sake of compability ? And I know Christian will "love" us for changing this so close to the book release ;) /max > -----Original Message----- > From: Max Andersen > Sent: Monday, July 17, 2006 10:51 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > point taken. > >> Well Type and UserType do not necessarily need to be in synch in this >> particular regard. We could conceivably change Type and then later >> (i.e. as part of a major release) change the UserType API to align it. >> After all the whole point of the UserType stuff was to insulate the > user >> from changes in the underlying Type system... >> >> -----Original Message----- >> From: Max Andersen >> Sent: Monday, July 17, 2006 10:43 AM >> To: Steve Ebersole; Hibernate development >> Subject: Re: [Hibernate] Roadmap - components >> >> On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole >> <[EMAIL PROTECTED]> wrote: >> >>> Type is *NOT* a public API... >> >> but UserType is - don't they need access to this info too ? >> >> /max >> >>> >>> -----Original Message----- >>> From: Max Andersen >>> Sent: Monday, July 17, 2006 10:38 AM >>> To: Steve Ebersole; Hibernate development >>> Subject: Re: [Hibernate] Roadmap - components >>> >>> ...but requires changes to public API so probably best suited for > 3.3. >>> >>>> Regarding the component related changes mentioned in the previous >>>> email... >>>> >>>> As I mentioned a lot of the pre-requisite work has already been >>>> performed on HEAD. I also took the opportunity to refactor the >>>> packaging of the org.hibernate.tuple package. Specifically, most of >>> the >>>> pre-requisite work was the introduction of the >>>> o.h.t.component.ComponentMetamodel class. Currently, ComponentType >>> just >>>> uses this new class directly. >>>> >>>> What needs to happen next, then, is for the introduction of a >>>> org.hibernate.persister.component.ComponentPersister which is > managed >>> as >>>> part of the session factory much like the other persisters. >>>> ComponentType will then need to look up its corresponding >>>> ComponentPersister based on a "role name" and use the capabilities > of >>>> that persister. The pattern here is very similar to >>>> EntityType/EntityPersister. The difficulty I ran into though was >> that >>>> ComponentType would then require access to the session factory (in >>> order >>>> to locate the persister) from within methods where it is currently >> not >>>> passed a reference to the session factory (specifically, this was >>>> methods like isSame(), isEqual(), compare(), getHashCode(), etc). >>> This >>>> gets to more general discussions we have had in the past regarding >> the >>>> scoping of Types. The solution is one of two things: >>>> 1) Devise some sort of scoping scheme where Types can unequivocally >> be >>>> "bound" to a session factory. This is obviously difficult given the >>>> current Hibernate.LONG, Hibernate.STRING, etc static references. > One >>>> thought here would be splitting types (and their interface >>>> appropriately) to define "static" Types and "scoped" Types... >>>> 2) Modify the Type interface to accept either a session or a session >>>> factory/entity mode combo for most methods (would not really matter >>> for >>>> methods like sqlTypes(), etc) >>>> >>>> As I mentioned before this then allows us to make the >>>> 'hibernate.bytecode.provider' and >>>> 'hibernate.bytecode.use_reflection_optimizer'. Down the road, it >> also >>>> allows us to implement discrimination-based inheritance for >>> components. >>>> >>>> >>>> >>> >> > ------------------------------------------------------------------------ >>> - >>>> Using Tomcat but need to do more? Need to support web services, >>> security? >>>> Get stuff done quickly with pre-integrated technology to make your >> job >>> >>>> easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>> Geronimo >>>> >>> >> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>> _______________________________________________ >>>> hibernate-devel mailing list >>>> hibernate-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel >>> >>> >>> >> >> >> > > > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
