ORM 5 Final - Release date and what's needed for OGM
by Gunnar Morling
Steve, all,
What's the planned for release date for ORM 5 Final?
For OGM, we'd need at least one post-CR2 fix, HHH-9906 (apply auto-quoting
setting correctly, [1]). That's already on master and I think it's small
enough to fall under a slightly relaxed "Final = Retagged last CR" policy.
In addition, a fix for HHH-9923 (Avoid cast to MetadataBuildingOptionsImpl
in AnnotationMetadataSourceProcessorImpl#prepare(), [2]) would be great.
It's no blocker for OGM atm. but it'll allow us to actually plug in custom
MetadataBuilders down the road.
Finally there is the potential issue around element collection column
naming I brought up recently [3]; I think I've found a good enough
work-around on the OGM side, but I feel this may better be fixed in ORM. As
is, no blocker from my POV, but an answer on this subject would be nice :)
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/HHH-9906
[2] https://hibernate.atlassian.net/browse/HHH-9923
[3] http://lists.jboss.org/pipermail/hibernate-dev/2015-July/013076.html
11 years
Another Jira feature removal
by Steve Ebersole
Public announcement service
According to our logs, a Cloud Connector integration with another product
is active on your instance. These connectors are no longer supported and
will be removed from JIRA on 27 July. Please refer to the below link for
migration details.
More information
<https://confluence.atlassian.com/display/JIRAKB/Cloud+connectors+removal+...>
I do not know what Cloud Connector we use. I looked at the link, but we do
not use any of those... maybe our old Fisheye intg is still active?
11 years
Naming strategies and collection element columns
by Gunnar Morling
Steve,
There is one remaining itch I have wrt. upgrading OGM to ORM 5.
I have an entity GrandMother with an @ElementCollection "grandChildren" of
type GrandChild. The latter has a property "name" which used to be passed
as "grandChildren.collection&&element.name" to OGM's
NamingStrategy#propertyToColumnName(). We used to detect the
"collection&&element" pattern to determine the right column name fin OGM.
As of ORM 5, this is passed as "grandChildren.name" instead (due to
HHH-6005 [1]). Now I thought
ImplicitBasicColumnNameSource#isCollectionElement() would tell me whether
this is a collection element, but it returns false in this case.
Shouldn't it return true if the replacement magic for HHH-6005 has kicked
in Ejb3Column#redefineColumnName()?
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/HHH-6005
11 years
Enum mapping in hbm.xml
by Steve Ebersole
This came up in getting the testsuite set up against MySQL. When an enum
is defined in hbm.xml we do not inherently know whether to treat it as
ordinal or named. We try a few different things to make this
determination, but ultimately if we do not have enough information up front
we prefer to defer the decision until later when we have access to some
form of JDBC metadata (generally nullSafeSet/nullSafeGet) to decide.
It seems there was initially a problem in that deference code that led
to HHH-8153[1]. However, the fix done for HHH-8153 is not enough.
Ultimately the problem is that the driver may not have the proper
information to answer java.sql.ParameterMetaData#getParameterType
correctly. HHH-8153 handles the case where the driver flat out does not
support that call and throws an exception. However MySQL illustrates
another case where the driver simply reports VARCHAR as the broadest
acceptable type. In other words it is not looking at the underlying
datatypes in the database. So even if the parameter is matched to the enum
column that we defined as numeric, the MySQL driver is still going to
return ParameterMetaData#getParameterType == VARCHAR.
I cannot say how many drivers implement this correctly. H2 does this as we
expect it. MySQL at least does not.
So the question becomes how we want to support enum types in hbm.xml. For
illustration, this can be seen in the org.hibernate.test.enums.EnumTypeTest
added for HHH-8153. The mapping is
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src....
Neither enum mapping works particularly "correctly", but the test failure
comes from the HairColor mapping. We expect that to be an ordinal, we
create the table with its column being a numeric, but then the driver says
the parameter type is VARCHAR and we try to treat it as named.
For what it is worth, I had quite a long time ago added the parameter
needed to properly control this in hbm.xml. The "proper" way to map these
would have been to use the "useNamed" type parameter:
<property name="gender" not-null="true">
<type name="org.hibernate.type.EnumType">
<param name="enumClass">org.hibernate.test.enums.Gender</param>
<param name="useNamed">false</param>
</type>
</property>
<property name="hairColor" not-null="true">
<type name="org.hibernate.type.EnumType">
<param name="enumClass">org.hibernate.test.enums.HairColor</param>
<param name="useNamed">true</param>
</type>
</property>
The rub is that to cater for legacy mappings, I do not "require" this, like
annotations do. This would be a non-issue if I could, during
configuration, say that an enum is ordinal if "useNamed" is not set or is
set to false and that it is named if useNamed is set to true. What is
missing/different is the not-set case. At them moment that falls back to
the JDBC metadata approach discussed above.
What I propose is that we change this. I am kind of torn as to the default
tbh. I think JPA's default of ORDINAL is the wrong choice. I think NAMED
is the better choice. Well technically I think an independent mapping code
it best. But strictly between ORDINAL/NAMED, I think NAMED is better. So
if everyone agrees that we change this to definitively determine the enum
mapping up front, which style do we choose as the default. Obviously the
big argument for choosing ORDINAL is consistency with annotations.
[1] https://hibernate.atlassian.net/browse/HHH-8153
11 years
org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX
by Gail Badner
AvailableSettings.EVENT_LISTENER_PREFIX is set to "hibernate.ejb.event". JpaIntegrator looks for ConfigurationService settings (which include properties) with that prefix, then strips off that prefix to determine the org.hibernate.event.spi.EventType.
I see that org.hibernate.event.spi.EventType has non-JPA event types. I can see that it could be useful for an application to specify non-JPA listeners to access Hibernate extensions. Is this what is intended?
Since JPA already defines annotations and <entity-listener> XML descriptors to specify JPA entity listeners/callbacks, should Hibernate continue to allow JPA entity listeners/callbacks to be specified using a property with this prefix?
In master, the only test I see that uses a property prefixed with "hibernate.ejb.event" is org.hibernate.jpa.test.packaging.PackagedEntityManagerTest. Also, I don't see any documentation for prefixing properties this way.
Should AvailableSettings.EVENT_LISTENER_PREFIX be deprecated?
Thanks,
Gail
11 years
ORM Team "triage" meeting
by Steve Ebersole
Gail and I discussed Jira a little bit last week and how to best manage
scheduling issues.
We both agreed that a team get together, either weekly or every-other-week,
to discuss new issues to triage them would be a great idea.
One thing I absolutely do not want happening is just scheduling issues as a
means to come back and triage them later. Scheduling an issue, on a "real
version" anyway, should mean something. It should mean some level of
dedication to finish that task for that release. In short, unless you are
volunteering to take on a task *yourself* for that release, please do not
schedule it for that release.
As for the triage meeting, I would definitely like Gail and Andrea
involved. Of course anyone is welcome. The reason I mention this is that
Gail is usually left on early side of scheduling these. So we will find a
time that works best for us 3 and go from there. I recommend that we
leverage HipChat for these discussion.
Andrea is coming to Austin for a few days starting Monday, so I would like
to start this triaging while he is here. Gail, I am thinking 1pm my time
(11am yours) would be a good time. Andrea, does that work for you after
Austin?
11 years
UUID as id
by Steve Ebersole
This goes to the feature we just added in 5.0 of supporting "non standard"
types as identifiers. Specifically UUID.
Sanne and I have been discussing the MySQL (MariaDB) tests hanging
recently. Well on the ORM side this was caused by an overly optimistic
tests not properly handling transactions and connections on an exception.
The underlying exception however comes from this support running against
MySQL. The UUID is treated as BINARY. The test inserts a row, and then
deletes it by id. The row is inserted no problem. However the delete by
id fails. Apparently MySQL is not liking comparisons using = based on
binary data.
The work around is to explicitly add @Column( length = 16 ). This is
planned to be addressed later via org.hibernate.type.Type#dictatedSizes
Just a heads up if ya'll run into this. I added a note to the migration
guide as well.
11 years
Hibernate Search fails to generate anything
by Dmitry Bocharov
Hello, everyone!
I'd like to discuss with you the problem. I'm writing a hibernate-search
eclipse plugin and currently I have a problem with generating indexes.
I try to generate indexes in HSearchServiceProxy class
<https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hse...>.
The code runs till the end fine. I was able to debug it. However, nothing
is created.
I have a user project. In hibernate.cfg.xml there is:
* <property
name="hibernate.search.default.directory_provider">filesystem</property>*
* <property
name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*
Also there is
* <dependency>*
* <groupId>org.hibernate</groupId>*
* <artifactId>hibernate-search-orm</artifactId>*
* <version>5.0.1.Final</version>*
* </dependency>*
in the *pom.xml* in order to annotate entities to index them:
*@Entity*
*@Indexed*
*public class Person implements java.io.Serializable {*
* @Id*
* @GeneratedValue*
* private int id;*
* @Field(analyze=Analyze.YES, store=Store.NO)*
* private String login;*
When i try to create indexes as a user - it works fine. However, when I try
to do it from my plugin nothing happens. I debugged and found that the call
stack is the following: MassIndexerImpl.startAndWait() ->
FullTextSessionImpl.getSearchIntegrator() ->
ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi) ->
SearchFactoryReference.getSearchIntegrator(). And here
<https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f4...>
it
creates and exception in getSearchIntegrator() because
this.extendedIntegrator returns null.
As I understand plugin classloader is different from user classloader. So
that can be a problem. In my plugin I have hibernate-core 4.3.1 (from
jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of this
jbosstolls-hibernate plugin) in the classpath. I found that versions are
compatible, so it's not a problem.
So the only problem, as I think, are different classloaders.
Koen Aers and Sanne Grinovero are in touch with the problem. So If anyone
else has any thoughts, it would be great to see =)
Thanks in advance!
Dmitry
11 years
