[hibernate-dev] Hibernate ORM 5.0.12.Final and 5.1.4.Final released!

[Gail Badner]

Note: These are the last releases in the 5.0/5.1 series. You will need
to migrate to 5.2 for future bugfixes.

http://in.relation.to/2017/01/19/hibernate-orm-5012-final-and-514-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - Type system

[Vlad Mihalcea]

There's a lot to dig in here. I'll have to get the branch and study the
changes, to come back with some opinions.

Vlad

On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole  wrote:

> We are getting pretty far along on the 6.0 changes and I wanted to start
> a(nother) discussion about Types in 6.0 to get feedback and thoughts on a
> few topics.
>
> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types
> and "persisters"...
>
> (a lot of this is the same from pre-6.0, just making things more explicit)
>
> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's
> start there.  A JavaTypeDescriptor is a descriptor of a given Java type.
> That is, it provides Hibernate with information about the Java type.  Is it
> a numeric type?  How do we compare 2 values of this type?  How do we make a
> deep copy of a value of this type?  Etc.  SqlTypeDescriptor is the same,
> but for a database type (VARCHAR, BLOB, etc).  These 2 work together to
> perform reading and writing at the JDBC-level.
>
> We decided to broadly categorize JavaTypeDescriptors based on the JPA type
> categorizations:
>
>1. BASIC - BasicJavaDescriptor
>   1. TemporalJavaDescriptor
>   2. NumericJavaDescriptor
>2. MANAGED - ManagedJavaDescriptor
>   1. EMBEDDABLE - EmbeddableJavaDescriptor
>   2. IDENTIFIABLE - IdentifiableJavaDescriptor
>  1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor
>  2. ENTITY - EntityJavaDescriptor
>
>
> Type (org.hibernate.type.spi.Type) represents a combination of a
> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a
> specific "non-root Navigable domain value".  Navigable is a query-focused
> contract (SQM/HQL/Criteria) so I wont get too deep into that here.  At a
> high-level t is similar to JPA's Bindable except that it applies to
> Collection indices (or map-keys) and elements (or map-values) as well.
> Navigable essentially represents an named navigation one can perform in a
> query.  The root Navigable is always an entity (EntityPersister).
> EntityPersister is the only Navigable that does not expose a Type.  (There
> is an EntityType, but it represents entity-valued non-root Navigables such
> as a ManyToOne).  All other navigables expose a Type.  That is all a
> long-winded way to say that Types represents that Java/SqlTypeDescriptors
> for a role-based Navigable.
>
> Like the categorization discussed above for JavaTypeDescriptor, Type has a
> similar categorization:
>
>1. Type
>   1. BasicType
>  1. TemporalType
>   2. AnyType
>   3. ManagedType
>  1. EmbeddedType
>  2. IdentifiableType
> 1. MappedSuperclassType
> 2. EntityType
>
> It is important to keep in mind that these represents a specific reference
> to thse things in regards to a Navigable.  E.g. an EntityType is the "type"
> of a SingularPersistentAttribute that is a ManyToOne - it points to the
> corresponding EntityPersister but it also represents the FK columns to
> refer to the entity.  It is a role-based Navigable.
>
> Historically reads and writes have all routed through the Type (with
> certain Types delegating much of that to persisters).  That will no longer
> be the case in 6.0 as one of the main design goals for 6.0 is to re-write
> how Hibernate reads and writes (mainly reads) values from JDBC.  The major
> shift here is to read all values from JDBC using a "SqlSelectionReader"
> equivalent to a BasicType.  These values are read and held in an array that
> "readers" then know how to access (positionally) and use.  Most of that
> design is beyond the discussion here, but it useful to understand.  It is
> discussed in the design.adoc in my orm-sqm poc repo for those curious.
> Long story, short... Types no longer directly implement JDBC read/write
> which we will come back to later.
>
> PersistentAttribute and the other Navigables now take a role in JDBC
> reads/writes.  AttributeConverters and other read/write-related concerns
> have been moved to these contracts.  Again, most of this is covered in the
> mentioned design doc.
>
> Since Type no longer directly implements JDBC read/write operations I think
> it is important to ask ourselves what exactly we see as "customizable" wrt
> each Type.  Is that different for each category, or the same across all
> Type categories?  E.g. I know of no customization of EntityType as it
> exists in 5.x, and tbh I am not even sure what that would mean.  BasicType
> obviously has some parts that we want to allow users to override, but is
> that really best achieved through a custom BasicType?  Or is it better
> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or
> SqlSelectionReader?  What about EmbeddedType?  CollectionType?  This would
> affect @TypeDef and Type registration methods specific to customizations.
>
> Persisters for the most part continue to serve the same role they have in
> the past with a 

Re: [hibernate-dev] Hibernate ORM Project - Getting Started on "SuitableForNewContributors" Jira Issues

[Steve Ebersole]

Hi Valerie!  Just comment on the issue that you are giving it a try and
work on it in a branch on your fork of hibernate-orm repo.  When you are
done, send us a pull request.

Thanks for your interest

On Thu, Jan 19, 2017, 9:57 AM Valerie Arena  wrote:

> Hello,
>
> I would like to contribute to Hibernate ORM and would like to work
> on "SuitableForNewContributors" Jira Issues. How do I get assigned to an
> issue?
>
> Thank You!
> Valerie Arena
> https://www.linkedin.com/in/arenavalerie
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 6.0 - Type system

[Steve Ebersole]

We are getting pretty far along on the 6.0 changes and I wanted to start
a(nother) discussion about Types in 6.0 to get feedback and thoughts on a
few topics.

First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types
and "persisters"...

(a lot of this is the same from pre-6.0, just making things more explicit)

JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's
start there.  A JavaTypeDescriptor is a descriptor of a given Java type.
That is, it provides Hibernate with information about the Java type.  Is it
a numeric type?  How do we compare 2 values of this type?  How do we make a
deep copy of a value of this type?  Etc.  SqlTypeDescriptor is the same,
but for a database type (VARCHAR, BLOB, etc).  These 2 work together to
perform reading and writing at the JDBC-level.

We decided to broadly categorize JavaTypeDescriptors based on the JPA type
categorizations:

   1. BASIC - BasicJavaDescriptor
  1. TemporalJavaDescriptor
  2. NumericJavaDescriptor
   2. MANAGED - ManagedJavaDescriptor
  1. EMBEDDABLE - EmbeddableJavaDescriptor
  2. IDENTIFIABLE - IdentifiableJavaDescriptor
 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor
 2. ENTITY - EntityJavaDescriptor


Type (org.hibernate.type.spi.Type) represents a combination of a
JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a
specific "non-root Navigable domain value".  Navigable is a query-focused
contract (SQM/HQL/Criteria) so I wont get too deep into that here.  At a
high-level t is similar to JPA's Bindable except that it applies to
Collection indices (or map-keys) and elements (or map-values) as well.
Navigable essentially represents an named navigation one can perform in a
query.  The root Navigable is always an entity (EntityPersister).
EntityPersister is the only Navigable that does not expose a Type.  (There
is an EntityType, but it represents entity-valued non-root Navigables such
as a ManyToOne).  All other navigables expose a Type.  That is all a
long-winded way to say that Types represents that Java/SqlTypeDescriptors
for a role-based Navigable.

Like the categorization discussed above for JavaTypeDescriptor, Type has a
similar categorization:

   1. Type
  1. BasicType
 1. TemporalType
  2. AnyType
  3. ManagedType
 1. EmbeddedType
 2. IdentifiableType
1. MappedSuperclassType
2. EntityType

It is important to keep in mind that these represents a specific reference
to thse things in regards to a Navigable.  E.g. an EntityType is the "type"
of a SingularPersistentAttribute that is a ManyToOne - it points to the
corresponding EntityPersister but it also represents the FK columns to
refer to the entity.  It is a role-based Navigable.

Historically reads and writes have all routed through the Type (with
certain Types delegating much of that to persisters).  That will no longer
be the case in 6.0 as one of the main design goals for 6.0 is to re-write
how Hibernate reads and writes (mainly reads) values from JDBC.  The major
shift here is to read all values from JDBC using a "SqlSelectionReader"
equivalent to a BasicType.  These values are read and held in an array that
"readers" then know how to access (positionally) and use.  Most of that
design is beyond the discussion here, but it useful to understand.  It is
discussed in the design.adoc in my orm-sqm poc repo for those curious.
Long story, short... Types no longer directly implement JDBC read/write
which we will come back to later.

PersistentAttribute and the other Navigables now take a role in JDBC
reads/writes.  AttributeConverters and other read/write-related concerns
have been moved to these contracts.  Again, most of this is covered in the
mentioned design doc.

Since Type no longer directly implements JDBC read/write operations I think
it is important to ask ourselves what exactly we see as "customizable" wrt
each Type.  Is that different for each category, or the same across all
Type categories?  E.g. I know of no customization of EntityType as it
exists in 5.x, and tbh I am not even sure what that would mean.  BasicType
obviously has some parts that we want to allow users to override, but is
that really best achieved through a custom BasicType?  Or is it better
served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or
SqlSelectionReader?  What about EmbeddedType?  CollectionType?  This would
affect @TypeDef and Type registration methods specific to customizations.

Persisters for the most part continue to serve the same role they have in
the past with a few additions and some changes...

One addition was the creation of an EmbeddedPersister.  *Embedded*.  This,
like CollectionPersister, models a "role" e.g. "Person.name" as opposed to
the Embeddable Name.class.  Note however that JPA calls it an
EmbeddableType and expects info about the Embeddable (the Class).
EmbeddedPersister is role-based (Embedded) instead, which 

[hibernate-dev] Hibernate ORM 5.2.7.Final has been released

[andrea boriero]

For details:
http://in.relation.to/2017/01/19/hibernate-orm-527-final-release
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM Project - Getting Started on "SuitableForNewContributors" Jira Issues

[Valerie Arena]

Hello,

I would like to contribute to Hibernate ORM and would like to work
on "SuitableForNewContributors" Jira Issues. How do I get assigned to an
issue?

Thank You!
Valerie Arena
https://www.linkedin.com/in/arenavalerie
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting 5.2.7 release

[andrea boriero]

Please do not push anything to master branch.

Thanks,

Andrea
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev