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
9 years, 10 months
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
9 years, 10 months
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
9 years, 10 months
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...
9 years, 10 months
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.
9 years, 10 months
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
9 years, 10 months
Batch version data support in Dialect
by Vlad Mihalcea
Hi,
While browsing the PRs on GitHub, I stumbled on this issue:
https://hibernate.atlassian.net/browse/HHH-10290
In the current implementation, the hibernate.jdbc.batch_versioned_data
property is set to true and
we override it at Dialect-level as follows:
public Oracle12cDialect() {
super();
getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA,
"true" );
}
Wouldn't it be better if the Dialect had a methods like:
boolean supportsBatchVersionedData();
and we wouldn't change the environment setting?
With this method added, the user can override the Dialect setting using the
environment variable.
With the current implementation, we always override that setting.
Vlad
9 years, 10 months
