hibernate-devel

Re: [Hibernate] Roadmap - components

[Steve E. <ste...@jb...>]

Type is *NOT* a public API...

-----Original Message-----
From: Max Andersen=20
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 =20
> Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Steve E. <ste...@jb...>]

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=20
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 =20
<ste...@jb...> 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=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
>> _______________________________________________
>> hibernate-devel mailing list
>> hib...@li...
>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Max R. A. <max...@jb...>]

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 us=
er
> 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
> <ste...@jb...> 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 manage=
d
>> 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 o=
f
>>> 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.  On=
e
>>> 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=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>>> _______________________________________________
>>> hibernate-devel mailing list
>>> hib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>
>>
>>
>
>
>



-- =

--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Steve E. <ste...@jb...>]

I started down the path of changing the Type interface to have the
majority of methods accept a SessionFactoryImplementor.  That is
something I would like to avoid if possible.  Why?  Well, this ended up
affecting the vast majority of the entire codebase; which in turn meant
increasing the footprint of certain often used classes in order to add a
reference to the session factory just so they could pass it into these
modified Type methods.

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...

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.

=20
-----Original Message-----
From: Max Andersen=20
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
> <ste...@jb...> 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=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
>>> _______________________________________________
>>> hibernate-devel mailing list
>>> hib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>
>>
>>
>
>
>



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Max R. A. <max...@jb...>]

> 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 nee=
d
> 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 o=
n
> 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 bo=
ok  =

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
>> <ste...@jb...> 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 o=
f
>>> 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 th=
e
>>>> 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 sessio=
n
>>>> 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=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>>>> _______________________________________________
>>>> hibernate-devel mailing list
>>>> hib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- =

--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Steve E. <ste...@jb...>]

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=20
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 =20
needed or
would it be better to just get it over with.

Still, *alot* of code will break for this :( (luckily it is =20
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 =20
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 =20
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
>> <ste...@jb...> 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=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
>>>> _______________________________________________
>>>> hibernate-devel mailing list
>>>> hib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>>
>>>
>>>
>>
>>
>>
>
>
>



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Max R. A. <max...@jb...>]

Regarding handling users migration of code then I guess (one of) the wor=
st
parts is where users have query/criteria building code that does not hav=
e
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 a=
re
> 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 wa=
y
> 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 th=
e
>> "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 mor=
e
> 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 thi=
s
>>> 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
>>> <ste...@jb...> 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, ComponentTyp=
e
>>>> 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 unequivocall=
y
>>> 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 matte=
r
>>>> 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=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>>>>> _______________________________________________
>>>>> hibernate-devel mailing list
>>>>> hib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- =

--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Steve E. <ste...@jb...>]

I guess it depends on which pieces of code you are thinking about
specifically in regards to Criteria.  For example, for the most part
users really should not ever need explicit types any longer when dealing
with HQL queries because of the changes I have recently put in place
regarding looking at the context in which that "typed node" is used and
inferring the proper type based on that; they only ever really need to
use a specific type when wanting to do something out of the ordinary
(like binding a DateType value to a parameter anticipated as a
TimestampType).  Would be great to include similar code into Criteria
queries; native sql queries would be much tougher.=20

At any rate, I've decided to hold off on this until something other than
a minor point release (3.3 maybe?) since it also requires some changes
to how the Configuration stuff works).

-----Original Message-----
From: Max Andersen=20
Sent: Tuesday, July 25, 2006 12:35 PM
To: Steve Ebersole
Cc: Hibernate development
Subject: Re: [Hibernate] Roadmap - components

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 =20
Query or Criteria.

They would have a hard time migrating code since they can't rely on =20
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
>>> <ste...@jb...> 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=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
>>>>> _______________________________________________
>>>>> hibernate-devel mailing list
>>>>> hib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...

Re: [Hibernate] Roadmap - components

[Max R. A. <max...@jb...>]

On Mon, 17 Jul 2006 17:41:25 +0200, Steve Ebersole  =

<ste...@jb...> 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 tha=
t
>> ComponentType would then require access to the session factory (in
> order
>> to locate the persister) from within methods where it is currently no=
t
>> 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 th=
e
>> scoping of Types.  The solution is one of two things:
>> 1) Devise some sort of scoping scheme where Types can unequivocally b=
e
>> "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 als=
o
>> 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 jo=
b
>
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>>
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>> _______________________________________________
>> hibernate-devel mailing list
>> hib...@li...
>> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>
>



-- =

--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...