More Dialect and quoting fun
by Steve Ebersole
What follows is solely an issue with schema update and schema validation, 2
tools that to date we have not "really" supported, but I am trying to
change that with 5.0.
We discussed before the idea of auto-quoting and who should be the
authority in regards to keywords. We decided that it would be Dialect, for
Dialects that chose to do it, rather than the JDBC DatabaseMetaData.
However there is another piece to this that we currently miss. It has to
do with the following methods:
* java.sql.DatabaseMetaData#storesMixedCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesLowerCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesUpperCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesMixedCaseIdentifiers
* java.sql.DatabaseMetaData#storesUpperCaseIdentifiers
* java.sql.DatabaseMetaData#storesLowerCaseIdentifiers
We already have bug reports that come directly from drivers not
implementing these "properly".
They come into play in the implementation of the following methods (on
org.hibernate.engine.jdbc.env.spi.IdentifierHelper):
* toMetaDataCatalogName
* toMetaDataSchemaName
* toMetaDataObjectName
* fromMetaDataCatalogName
* fromMetaDataSchemaName
* fromMetaDataObjectName
The to* methods are used when binding the Identifiers to the metadata
queries (DatabaseMetaData#getTables method e.g.). The from* methods are
used when extracting values from the results. We currently rely on the
answers to the referenced DatabaseMetaData methods to determine the
quoting->case conversion and case->quoting conversions.
My proposal is that we go a step further than what we did for Dialect and
auto-quoting. For that, we defined a
Dialect#determineKeywordsForAutoQuoting method and allowed Dialects to
override it if they wanted. The only time that method is used actually is
in building the IdentifierHelper instance. So my proposal is that we drop
Dialect#determineKeywordsForAutoQuoting and instead define a
Dialect#buildIdentifierHelper method. This could work one of 2 ways.
First, the Dialect#buildIdentifierHelper method accepts a DatabaseMetaData
and the base implementation would do what we do today. However,
DatabaseMetaData can very well be null. When we initialize
IdentifierHelper atm we assume some (H2 based) defaults. So going this
first route would mean each Dialect impl that wants to override this method
having to handle nulls there. Not ideal.
A second approach would be to have Dialect#buildIdentifierHelper accept
either no parameters or just one parameter which would be the same as what
is passed to Dialect#determineKeywordsForAutoQuoting. This would work such
that null returned from this method would mean to use a fallback approach
based on DatabaseMetaData.
What do y'all think?
10 years, 11 months
4.3
by Steve Ebersole
I am having trouble building 4.3 even from a clean checkout:
:hibernate-core:runSourceGenerators
:hibernate-core:runAnnotationProcessors FAILED
FAILURE: Build failed with an exception.
* Where:
Script
'/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
line: 305
11 years
Upgrades for ci.hibernate.org
by Sanne Grinovero
Hi all,
the build slaves for ci.hibernate.org got refreshed.
Several jobs failed during the last week as the micro quotas we had
were getting full.
The 4 nodes have now 4 times the RAM, 4 times the CPU and 8 times the
disk space.
(that's 15GB of RAM, 8 CPUs, 80GB of dedicated space per node)
N.B. both relational and NoSQL databases are running on a much smaller
18GB partition, shared with the OS system files. Tests are expected to
cleanup after use!
I've tested some of the main builds and they seem to run fine, but
there are various exotic jobs which don't get run too often.. please
let us know if you see something unusual.
Some things of note:
- I reconfigured the Gradle and Maven global environment (defaults)
to more generous heap sizes
-- you might want to do the same, if you did override those in your jobs
- the various JDKs got updated
- the HQL Parser project apparently was just verifying it could
successfully checkout the project.. fixed that to actually run the
build, and the tests too!
- it took Davide and me a couple of hours to figure how to script the
disk size changes, but the actual re-build from scratch of all slaves
only took minutes! eureka
- the HQL Parser is now experimenting with the Gradle option to run
parallel builds (try to get some benefits form all these cores)
-- I'm temporarily playing with the setting on Hibernate ORM too,
I'll probably return it to more conservative options soon ..
Remaining TODOs:
- merge the open PRs of ci.hibernate.org
- think of how to automate disk space reclaim? Or keep an eye on its growth
- Several Jenkins plugins need to be upgraded. I'd prefer we wait a
bit on that and verify first that most jobs build fine, to ease
diagnostics of all the things which break when those get updated..
Thanks,
Sanne
11 years
Support for DELETE statements ActionQueue sorting
by Mihalcea Vlad
Hi,
While INSERT sorting is handled by ActionQueue.InsertActionSorter, DELETE statements are not sorted at all.
A DeleteActionSorter woudl have to rearrange DELETES in the opposite order as the INSERT sorting, the Children having to be deleted first.
The current work-around is to dissociate all Children and manually flush the Session, so that the orphan-removal kicks in before the Parent entities delete occurs.
Any plans for supporting such a feature?
Vlad Mihalcea
11 years
[Search] Projections of collection of elements with embeddable
by Davide D'Alto
Hi,
while working on OGM-781 I noticed that there is a problem with Hibernate
Search when trying to get the projection of a property that represents a
collection of elements..
EntityInfo#getProjections()[0] will always return the first value of the
association.
For example, if I index the following entity:
@Indexed
public static class ExampleEntity {
@Field(store = Store.YES)
Integer someInteger;
...
@Field(store = Store.YES)
@IndexedEmbedded
List<Integer> someCollection;
}
and than add a projection on "someCollection"
EntityInfo.getProjection()[0] will only return the first result of the
collection instead of returning a List<Integer>.
This seems a bug to me.
I've already created a local branch that should fix the behaviour in this
case.
It also makes me wonder, what should we do with a list of embeddables?
For example:
@Field(store = Store.YES)
@IndexedEmbedded
List<ExampleEntity> nestedExamples
In this case, would it make sense to project "someCollection.someInteger"?
And what would be the expected result calling EntityInfo.getProjection()[0]?
Cheers,
Davide
11 years
ORM - FindBugs/PMD
by Steve Ebersole
Checkstyle in ORM is now good to go and enforced in the CI jobs.
So I started thinking about FindBugs. We do have FindBugs set up. However
it is utterly out of control at the moment. Maybe it's just me, but I find
FindBugs impossible to configure "well". Granted I have little experience
with it, but Web searches turn up almost nothing on how to configure
FindBugs. A few things in particular bug me about FindBugs:
1) Because it works on classes, not sources, it's nearly impossible to
succinctly say "ignore generated sources". Would love to be proved wrong
there :)
2) I am unsure how to tell FindBugs which rules to run and which to not. I
*think* this can be done through its filter files, but I have yet to find a
decent doc on doing that.
3) I have no idea how to change the confidence and severity of the things
FindBugs reports. I have mentioned the DM_CONVERT_CASE scenario to some of
you before. For us that is always a bug but FindBugs treats it with low
confidence (maybe a bug, maybe not).
I know PMD covers a lot of the same cases. Anyone familiar with it? lf it
is more easily configurable, maybe it fits our needs better...
11 years
Sharing IDE code styles
by Steve Ebersole
The recent discussion on Checkstyle got me thinking about best ways to
share/distribute code styles for IDE setup. Storing them in the project
itself is not very workable for IntelliJ at least. I started thinking
about a separate repository under the hibernate GitHub organization. Does
everyone use the code style I attached to
https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ, or
do y'all use custom versions of that?
Do y'all think it makes any sense to do this?
11 years
Hibernate O/RM Java 8 API.
by Jakub Narloch
Hi,
I would like to get back to last year idea, namely the the idea to
introduce new Java 8 API. Since that would not be possible to do directly
in Hibernate Core since it's backward compatibility with Java 6, I had
created a side project that introduces decorator/wrapper on top of
Hibernate Query API that introduces support for Streams<?> and retrieving
Optional<?> results.
I had already implemented the two basic ideas and was hopping for some kind
of feedback whether you would be interested in continouing this idea, also
a code review would be a usefull thing.
References:
Github project: https://github.com/jmnarloch/hibernate-streams-wrapper
JIRA issue: https://hibernate.atlassian.net/browse/HHH-9338
Regards,
Jakub Narloch
11 years
Checkstyle and ORM
by Steve Ebersole
FYI : https://hibernate.atlassian.net/browse/HHH-9803
Its not super high on my priority list, but I want to get to a point where
we can start to fail the build on "serious checkstyle regressions". Part
of that is being more realistic with what is considered serious, and part
of that is fixing up code.
For example, we have quite a few warnings about spaces rather than tabs for
indentation. That's a serious one to me. There are quite a few "unused
import" warnings, again to me that's serious (it just looks sloppy).
A few I have already disabled. Checking that there is a package-info.java
file for example. I'd love to make a requirement that all API and SPI
packages have one. But as far as I know that detailing is not available in
checkstyle, and I really dont overly care about package-info.java files for
internal packages.
These are just a few examples. #909[1] (still running atm) is the first
build with my preliminary work here. Let me know if there are any checks
anyone feels strongly about in one bucket or another.
[1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
11 years
