Regarding handling users migration of code then I guess (one of) the worst parts is where users have query/criteria building code that does not have direct access to the session or sessionfactory, but e.g. only have the Query or Criteria.
They would have a hard time migrating code since they can't rely on Hibernate.xxx for getting a proper Type. Could be made easier if query and criteria could tell which session they are from ? /max > Well this is just one pre-requisite for "cleaning up" how components are > modeled. Specifically, the piece I want to clean up is the fact that > components are currently handled differently than any other mapping > construct. When components are being parsed and bound (during config > time) they require construction of and access to things that are > typically only available after SF construction (runtime) for all other > mapping contructs. This mis-alignment causes some goofiness in the way > ComponentTypes are built and, even more importantly, some goofiness in > some of the things upon which ComponentTypes currently depend. > > Yes, one of these is how bytecode providers are handled. Another is > PropertyAccessors. Yet another is ComponentTuplizers. > > -----Original Message----- > From: Max Andersen > Sent: Monday, July 24, 2006 2:18 AM > To: Steve Ebersole; Hibernate development > Subject: Re: [Hibernate] Roadmap - components > > >> 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
