"matching" table/column names (and naming strategies)
by Steve Ebersole
This is something that has been bothering me for a long time. HHH-6328[1]
is a specific example. Basically we are very inconsistent in how we
attempt to match up table and column names, especially when there are
naming strategies involved. We see this with secondary tables,
@org.hibernate.annotations.Table, etc.
Consider the following mapping:
@Entity
@Table( name="`USER`" )
class User {
...
}
The question is how they should refer to this table in other annotations
such as @Column or @org.hibernate.annotations.Table e.g.
And part of this gets to whether the implicit or physical naming strategies
should have any part in the matching process. I think I am not a fan of
the mapping having to change just because they plug in a new naming
strategy. So ideally I'd prefer that the naming strategies not take part
in this process.
I guess I just wanted to start a discussion about how to best deal with
this.
One option is that they need to match exactly (maybe with some simple
handling of quoted versus case-insensitive, similar to Identifier#equals
leveraging Identifier#getCanonicalName), e.g.:
@Entity
@Table( name="`USER`" )
@org.hibernate.annotations.Table( appliesTo="`USER`", ... )
class User {
...
}
I guess the first question here is whether we want to support referring to
implicit table names in other annotations at all. JPA for the most part
discourages this; in order for a table name to be referenced in other
annotations it should be named explicitly.
Another option is to leverage the "logical name" (implicit or explicit) and
to apply a Identifier#equals-like check for matching. This would however
lead to what I mentioned above wrt naming strategies playing a part in the
matching. Consider we base matching on the logical name and that we have:
@Entity
@org.hibernate.annotations.Table( appliesTo="user", ... )
class User {
...
}
So this *might work* depending on the configured naming strategies. But it
is also therefore highly dependent upon the naming strategies and changing
the naming strategy could conceivably cause the match to no longer find the
table.
A sort of hybrid approach between those 2 would be to use a specific
"matchable name determination strategy" (think JPA implicit naming rules).
At the very least, as HHH-6328 shows again, we really ought to stay away
from simple String comparisons. Even a simple move to using Identifier for
the comparisons would help in that specific area.
[1] https://hibernate.atlassian.net/browse/HHH-6328
7 years, 9 months
Dropping "Serializable" requirement for IDs ?
by Sanne Grinovero
Hi all,
today creating a unit test I was greeted by this "old friend":
> org.hibernate.MappingException: Composite-id class must implement Serializable:
shall we get rid of this requirement?
It's just an inconvenience for end users to have to remember this
marker, as far as I know we don't really need this anymore.
I realise some code might still be needing this, but we probably can
do better by not actually serializing it with the default platform
serializer?
Just an idea for a potential 6.0 improvement..
Thanks,
Sanne
7 years, 9 months
Hibernate OGM 5.0.1.Final released
by Davide D'Alto
We released Hibernate OGM 5.0.1.Final!
What’s new?
Here some of the most interesting bug fixes and improvements in this release:
- OGM-818 - Autodetection support for @Entity annontated classes will now work
- OGM-356 - Object comparison in JPQL queries for MongoDB and Neo4j
(Thanks joexner!)
- OGM-1065 - You can now use Hibernate OGM with Cassandra 3
More information in the blog post:
http://in.relation.to/2016/07/04/hibernate-ogm-release-5
We are looking forward to hear your feedback,
Davide
7 years, 9 months
Fwd: Non-final dependencies in hibernate-core.gradle
by Gunnar Morling
Thanks for clarifying! Sent
https://github.com/hibernate/hibernate-orm/pull/1464 for updating these
versions.
--Gunnar
2016-06-30 15:02 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
> That was just the latest when we updated those for JPA 2.1
>
> On Thu, Jun 30, 2016 at 6:02 AM Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>
>> Hi,
>>
>> I noticed that a preview release of CDI is specified as dependency for the
>> ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].
>>
>> Is there a reason for using this specific one, or can we change it to the
>> Final (version "1.1")? Similarly for Weld
>> ("org.jboss.weld:weld-core:2.0.0.Beta6") and EJB API
>> ("org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:1.0.0.Alpha2").
>>
>> I can send a patch to change it, just wanted to be sure it's nothing
>> intentional.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/hib...
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
7 years, 9 months
HHH-10888
by Gail Badner
Currently, Hibernate's implementation of
javax.persistence.metamodel.PluralAttribute#isAssociation always returns
true. I haven't found anything in JSR 338 (yet) that refers to an element
collection as an association.
I don't see a good definition of "association", but the term is used with
respect to entities. I also see examples of @ElementCollection with
@AttributeOverride, but none with @AssociationOverride.
The change suggested in HHH-10888 is to have
PluralAttributeImpl#isAssociation return true only for one-to-many and
many-to-many. I believe this is correct, but it breaks a couple of tests
that specifically check if an element collection is an association.
I wanted to pass this by you in case I'm missing something here.
Please take a look at the pull request to see the fix and the required test
changes. [1]
Thanks,
Gail
https://github.com/hibernate/hibernate-orm/pull/1447
7 years, 9 months
