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
8 years, 9 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
8 years, 9 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...
8 years, 9 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.
8 years, 9 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
8 years, 9 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
8 years, 9 months
SQM and Query#getReturnTypes
by Steve Ebersole
There are a few reasons I want to remove Query#getReturnTypes. At least in
its current form. Currently it simply returns the Hibernate Type(s) that
the query will return.
One of the big reasons I want to remove this method is that it is simply
not expressive enough to handle some not-so-edge-cases like dynamic
instantiation queries (we'd have no idea about a Type for the
instantiation).
So the main question is whether to simply remove that method or whether
some representation of the Query return(s) is valuable. If this
information is deemed valuable, the idea would be to develop a contract
that caters to both "normal selections" and dynamic instantiations.
8 years, 9 months
