IntelliJ 16 and Java 8 for tests
by Steve Ebersole
We have been having an ongoing discussion about using Java 8 features in
tests. My only argument against that was the fact that doing so makes it
impossible to run tests in IDE (IntelliJ at least) unless I set the
"language level" for the whole module to Java 8 which means I possibly miss
using Java 8 calls in src/main.
Well IntelliJ 16 is in EAP and I have been using it for almost a week now.
One of its major changes is a move to a more Gradle-like view of a module
on importing a Gradle project. So when I import ORM, hibernate-core e.g.
is split up into 2 IntelliJ modules... or more correctly one per
SourceSet. Now I can set the "language level" independently of main versus
test.
So once IntelliJ 16 becomes more stable, I think we can consider allowing
Java 8 features in tests if anyone still wants to.
10 years
Stored procedure improvement
by Vlad Mihalcea
Hi,
While writing the stored procedure section, I found a way to improve the
current implementation to FUNCTIONS as well.
Considering the following function:
CREATE FUNCTION fn_post_comments(postId integer)
RETURNS integer
DETERMINISTIC
READS SQL DATA
BEGIN
DECLARE commentCount integer;
SELECT COUNT(*) INTO commentCount
FROM post_comment
WHERE post_comment.post_id = postId;
RETURN commentCount;
END
We could call this function and fetch the result ith plain-old JDBC:
session.doWork(connection -> {
try (CallableStatement function = connection.prepareCall("{ ? =
call fn_count_comments(?) }")) {
function.registerOutParameter(1, Types.INTEGER);
function.setInt(2, 1);
function.execute();
int commentCount = function.getInt(1);
assertEquals(2, commentCount);
}
});
When using the JPA 2.1 API:
StoredProcedureQuery query =
entityManager.createStoredProcedureQuery("fn_count_comments");
query.registerStoredProcedureParameter("postId", Long.class, ParameterMode.IN);
query.setParameter("postId", 1L);
Long commentCount = (Long) query.getSingleResult();
We get a "PROCEDURE fn_count_comments does not exist" exception because the
SQL statement is built as "{call fn_count_comments(?)}" instead of "{ ? =
call fn_count_comments(?) }".
I think we could define a hint like this:
query.setHint(QueryHints.HINT_CALL_FUNCTION, true);
So we could adjust the callable statement to work like a function.
What do you think of this?
Vlad
10 years
No Validator docs again
by Hardy Ferentschik
Hi,
The Validator docs are again vanished from the docs server? Does anyone know
what's going on?
@Steve, did you not restore them?
@Sanne, what happened to the backup you have been talking about
@all, any idea what's going on?
--Hardy
10 years
5.1 ORM docs
by Steve Ebersole
At this point the 5.1 documentation is all hosted[1] and the hibernate.org
website updated to reflect this[2].
Consolidating a lot of simultaneous discussions going on, the remaining
tasks imo:
1. Develop an answer for the SEO problem. Whether that can be achieved
continuing to use the JBoss doc server, or whether that involves us moving
hosting of the docs somewhere else being the first decision-point.
2. Design of the hibernate.org website around multiple doc versions.
You can start to see the fugliness of my temporary hack solution using
multiple nav-links. We need to design a good solution for this into the
site generation imo
3. Styling of these new asciidoctor-generated docs. Work on this is
already under way[3]
[1] http://docs.jboss.org/hibernate/orm/5.1/
[2] http://hibernate.org/orm/documentation
[3] https://issues.jboss.org/browse/DESIGN-737
10 years
JSR 354 - Money and Currency
by Steve Ebersole
So it sounds like JSR 354 may not be included in Java 9. Do we still want
to support this for ORM 5? I am not sure if "moneta" requires Java 9...
10 years
documentation translations
by Steve Ebersole
The translations of the ORM documentation (at least) is completely out of
date. Has been for many years. To the point where we stopped even
publishing translations.
So at this point, as we migrate to Asciidoc(tor) and make changes to doc
hosting do we plan for eventual translations? Or do we move forward
assuming no translations?
At the end of the day this is a simple point in that I need to know whether
to preserve the en-US directory in the publishing or not. But if we do not
plan on having translations, it seems odd to even deal with these language
dirs.
10 years
Eager fetch and duplicates of collection elements
by Gunnar Morling
Hi,
I understand that $subject is a known source of confusion for people
when working with HQL/criteria queries and not applying something like
DistinctRootEntityResultTransformer.
I am seeing the same behaviour though when getting a root entity by id
and join-fetching two (nested) collections. That's my model:
@Entity
public class Parent {
@Id @GeneratedValue
private Long id;
@OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
@JoinColumn(name = "parent_id")
private List<Child> children = new ArrayList<>();
}
@Entity
public class Child {
@Id @GeneratedValue
private Long id;
@ElementCollection(fetch=FetchType.EAGER)
@JoinTable(name = "Child_Properties")
@MapKeyColumn(name = "key")
@Column(name = "value")
private Map<String, String> properties = new HashMap<>();
}
I am persisting a parent with one Child which has three "properties"
entries. Loading the Parent by id yields three elements in the
"children" list:
Parent loaded = session.get( Parent.class, 123 );
assert 1 == loaded.getConfigurations().size(); // <!-- Fails, it
contains the same Child three times
I don't think that's expected?
I can file an issue, but first wanted to make sure I am not missing
anything obvious.
Thanks,
--Gunnar
10 years
