6.0 - Query literal rendering
by Steve Ebersole
Currently in 6.0 I have code in place to render query literals as
PreparedStatement parameters, but only outside the SELECT clause. Many DBs
require special handling for parameters defined in the SELECT clause
general requiring to wrap in cast functions calls.
I think it may be beneficial to allow the user to control this via a
setting. Specifically a multi-valued (enum) value with the following
possibility set:
1. NEVER
2. ALWAYS
3. OUTSIDE_SELECT
First, does anyone have an issue with this proposal? Secondly does anyone
see other concerns that should be take into account?
9 years, 3 months
AttributeConverter - 6.0
by Steve Ebersole
When I first added support for AttributeConverter I incorporated it into
BasicType because that was really the only option at the time.
As we move into 6.0 though I would like to consider moving this to the new
Attribute model. What this means practically speaking is that we'd
move AttributeConverter from the definition of BasicType and instead move
it to select "domain model reference nodes" identified by a
new ConvertibleDomainReference interface. This is already developed
initially in the 6.0 wip where basic singular attributes, basic collection
indexes and basic collection elements are all considered
ConvertibleDomainReferences.
This work so far only makes the AttributeConverters available
via ConvertibleDomainReference; it does not apply AttributeConverters
via ConvertibleDomainReference. That would be the next step if we decide
to go this route.
Additionally, this would mean that BasicType would no longer contain the
AttributeConverter; BasicType then would be the composition of:
1. JavaTypeDescriptor
2. SqlTypeDescriptor
3. MutabilityPlan
But even MutabilityPlan... I wonder if that should move to the Attribute
model as well?
Anyway, please let me know what y'all think of these open questions asap as
I'd like to start nailing down the Type SPIs for an Alpha.
9 years, 3 months
Jenkins upgrade on CI
by Davide D'Alto
Hi,
I'm going to upgrade our Jenkins on CI next week, the 27th of December.
This could be a relatively safe procedure but because our version is
old and we are using several plugins I'm not sure it will go smoothly.
If you have some jobs that need to be executed that day, let me know.
Davide
9 years, 4 months
SQM - PoC design doc
by Steve Ebersole
I have pushed a newly updated version of the design.adoc bringing the
discussions up-to-date with the latest code/design.
This PoC work is getting very far along and I really have not had much
feedback. My concern is that this code is only going to become harder to
review (more to look at) as more time passes.
I know digging in the code (it is a lot) is not really feasible, but please
at least take some time to look over the design.adoc in the poc repo.
Feedback sooner is better :)
9 years, 4 months
EntityGraph query spaces not applied to Query (HHH-11213)
by Gail Badner
Query spaces for EntityGraph nodes/subgraphs are not currently added
when applied to a Query, and so the session is not flushed if it
contains updated data relevant to the EntityGraph that is not in the
query spaces defined for the Query.
I originally though this was a critical issue, but now that I'm
looking into it, I'm not so sure. I am having a hard time coming up
with a test case where it matters.
I've created a pull request with the test case attached to HHH-11213,
with some added checks to detect if the session flushes. [1]
In this case, the session does not flush, but the query results are
still correct because the updated entity is taken from the Session,
not from the ResultSet returned by the query.
I wonder now if it really is necessary to flush the Session when the
session has updates that apply *only* to the EntityGraph (and not to
the base Query).
Thoughts?
Thanks,
Gail
[1] https://github.com/hibernate/hibernate-orm/pull/1707
9 years, 4 months