Regarding release versioning
by Vlad Mihalcea
Hi,
I have seen the frustration from the Spring Data team trying to keep up
with our code changes that break their integrations,
and I was wondering if we should use some Release candidates prior to
releasing a start of a branch, even if it's a minor one.
This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
that to mark it as an intermediary release that's aimed for early
adopters/integrators.
Do you think this is feasible or is there something to prevent us from
doing this?
Vlad
8 years, 6 months
SQL query interceptor
by Vlad Mihalcea
Hi,
During testing, it's very useful to have an SQL query interceptor that we
can inspect to see if the generated SQL query contains a certain SQL clause.
There are multiple ways we could implement this kind of feature:
1. We could add a public String[] getSQLQueries(); in the Statistics
interface.
2. We could define a SQLStatementInterceptor interface that can be provided
via some configuration property.
The SqlStatementLogger.logStatement could call the
SQLStatementInterceptor as well.
3. We could provide a way to provide a custom SQLStatementLogger class, so
that users can intercept statements via their custom SQLStatementLogger.
Currently, the only solution is to overwrite the sqlStatementLogger field
of the JdbcServicesImpl via Reflection, which is rather a hack.
What do you think?
Vlad
8 years, 6 months
RequiresDialects vs RequiresDialect
by Vlad Mihalcea
Hi,
While writing a cross-dialect test, I bumped into the following issue:
https://hibernate.atlassian.net/browse/HHH-10814
The question is why do we have a @RequiresDialects annotation:
@RequiresDialects({
@RequiresDialect(PostgreSQL81Dialect.class),
@RequiresDialect(Oracle8iDialect.class)
})
when @RequiresDialect can take multiple dialects as well:
@RequiresDialect({ Oracle8iDialect.class, PostgreSQL81Dialect.class} )
Vlad
8 years, 6 months
Re: [hibernate-dev] Relations are not loaded when using Fetch Profiles
by Vladimir Martinek
MetamodelGraphWalker line 144. My relation is in
MetamodelGraphWalker.visitedAssociationKeys, so it gets skipped and thus
not make it in the final big SQL SELECT.
Why don't you take a look at the test case I provided - just run it and
see the LazyInitializationException error, it will all be instantly
clear. I am talking about LAZY relations in combination with
FetchProfile using FetchMode.JOIN. Please disregard EAGER (for now, we
may come to that later once we agree on what is the problem :)
We prefer to have all relations LAZY on our project (performance
reasons) and use FetchProfiles. The actual FetchMode (whether it is
JOIN, SELECT) does not matter to us, all we need is the relations to be
loaded in single EntityManager.find call. Unfortunately the only
FetchMode implemented now is JOIN and that one has this unpleasant bug
in it.
Thank you
Vladimir
On 06/07/2016 04:01 PM, Steve Ebersole wrote:
> MetamodelGraphWalker does not consider them cycles. Where do you see
> MetamodelGraphWalker making that decision? MetamodelGraphWalker simply
> walks your model mappings. It delegates to pluggable strategies. So
> I assume you really mean one of the AssociationVisitationStrategy
> implementations is considering them cycles. And even then I am not so
> sure that is what happens...
>
> So to be clear we are talking about 2 different EAGER fetch strategies
> here: join and select.
>
> For join, we'd build one big SQL SELECT joining the relations
> together. You can see this by switching your associations from lazy to
> all being eager and specifying join fetching.
>
> For select, we'd build one SQL SELECT for the root entity being loaded
> (and any join fetched relations). From there, any select-fetched
> relations would be loaded individually by separate select (that's kind
> of the definition of N+1).
>
>
>
> On Tue, Jun 7, 2016 at 8:50 AM Vladimir Martinek <vm(a)sykora.cz
> <mailto:vm@sykora.cz>> wrote:
>
> Hello,
>
> actually I would like to learn how the FetchMode.JOIN is supposed
> to work in case of cycles (not really cycles but
> MetamodelGraphWalker considers them cycles).
>
> Check the test case please - it gets LazyInitializationException
> on a relation despite that relation being marked as JOIN FETCH in
> the fetch profile.
>
> How is this intended to work? Is it a problem of
> MetamodelGraphWalker and its cycle detection? Or is it planned
> limitation of FetchMode.JOIN?
>
> I can help to fix this, but in order to do that I need to know how
> this is expected to work.
>
> Please disregard EAGER. I only mentioned FetchType.EAGER because I
> noticed it can cope with the same cyclic relations - and yes, you
> are right, those are fetched in subsequent selects. But we can't
> use EAGER (performance reasons).
>
> Thank you
>
> Vladimir
>
>
>
>
>
> On 06/07/2016 03:05 PM, Steve Ebersole wrote:
>> There is a huge difference in join-fetch and what we detail for
>> "EAGER". Join-fetch is also an eager fetch. There are 2 pieces
>> of information in regards to fetching: when, how?
>>
>> EAGER merely describes when: now.
>>
>> What you describe as "EAGER" is really a N+1 fetch. So the
>> relation is fetched immediately, but as "subsequent select". A
>> join-fetch is still EAGER, but now the relation is fetch via join
>> in the initial query. Very different behavior.
>>
>> On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek <vm(a)sykora.cz
>> <mailto:vm@sykora.cz>> wrote:
>>
>> HHH-10745, runnable test case attached to that issue
>> (org.hibernate.test.fetchprofiles.cycle.tar.gz).
>>
>> Thank you
>>
>> Vladimir
>>
>>
>>
>> On 06/07/2016 06:00 AM, Gail Badner wrote:
>> > Please create a Jira issue and attach a runnable test case.
>> > Thanks,
>> > Gail
>> >
>> > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek
>> <vm(a)sykora.cz <mailto:vm@sykora.cz>
>> > <mailto:vm@sykora.cz <mailto:vm@sykora.cz>>> wrote:
>> >
>> > Fetch profiles fail to load certain relations because
>> of invalid cycle
>> > detection in MetamodelGraphWalker. Below is an example.
>> >
>> > I have compared the behaviour of Fetch Profiles and
>> standard EAGER
>> > relations (EAGER does not suffer from this problem). The
>> > MetamodelGraphWalker graph walker produces the same
>> results, the
>> > SQL is
>> > the same (missing relation).
>> >
>> > With EAGER the relation is loaded in second pass, via
>> > SessionImpl.internalLoad(). There it is decided what
>> LoadType is
>> > used -
>> > for eager it uses INTERNAL_LOAD_EAGER, for lazy
>> INTERNAL_LOAD_LAZY. It
>> > does not take into account the fetch profiles here!
>> >
>> > The last place I can get hold of fetch profiles in in
>> > AbstractLoadPlanBasedEntityLoader line 82. After that
>> the fetch
>> > profile
>> > information is lost, never making it anywhere near to
>> > SessionImpl.internalLoad().
>> >
>> > I would like to implement this, but to do that, I need
>> someone to
>> > point
>> > me in the right direction. Most of all I need answers
>> to following
>> > questions:
>> >
>> > 1) Is it right to assume the fetch profiles should be
>> evaluated in
>> > SessionImpl.internalLoad() and appropriate LoadType
>> used when
>> > detected a
>> > relation affected by a fetch profile?
>> > 2) If so, what is the intended way of getting the fetch
>> profile
>> > information to SessionImpl.internalLoad()?
>> >
>> > Also, a colleague of mine attempted to implement
>> FetchType.SELECT
>> > fetch
>> > strategy and ended up with precisely the same problem.
>> I believe
>> > solving
>> > my issue would pave way for quick FetchType.SELECT
>> implementation
>> > (which
>> > we could also use on our project).
>> >
>> >
>> > Thank you
>> >
>> > Vladimir Martinek
>> >
>> >
>> > Example:
>> >
>> > Have 5 entities - Start, Via1, Via2, Mid and Finish
>> with following
>> > relations (all LAZY):
>> >
>> > Start n:1 Via1 n:1 Mid n:1 Finish
>> > Start n:1 Via2 n:1 Mid n:1 Finish
>> >
>> > Now, trying to use Fetch Profiles to load Start entity
>> and all of its
>> > relations. I would expect Hibernate to execute
>> following SQL select:
>> >
>> > SELECT * FROM Start s
>> > LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>> > LEFT OUTER JOIN Mid
>> > JOIN Finish
>> >
>> > LEFT OUTER JOIN Via2 (path Start-Via2)
>> > LEFT OUTER JOIN Mid
>> > JOIN Finish
>> >
>> > Unfortunately, ii ompletely omits the second join from
>> Mid to Finish,
>> > what I am getting is:
>> >
>> > SELECT * FROM Start s
>> > LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>> > LEFT OUTER JOIN Mid
>> > JOIN Finish
>> >
>> > LEFT OUTER JOIN Via2 (path Start-Via2)
>> > LEFT OUTER JOIN Mid
>> >
>> > I dug deeper into this and found cycle detection in
>> > MetamodelGraphWalker, line 144. Basically, when
>> MetamodelGraphWalker
>> > detects a relation that has already been visited, it
>> considers it a
>> > cycle. But in my case it is not a cycle - I just came
>> to the same
>> > relation twice using two different paths.
>> >
>> >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.jboss.org>
>> <mailto:hibernate-dev@lists.jboss.org
>> <mailto:hibernate-dev@lists.jboss.org>>
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>>
>>
>> --
>>
>> *Ing. Vladimír Martinek*
>> Programmer
>>
>> T: +420 723 908 968
>> @: vm(a)sykora.cz <mailto:vm@sykora.cz>
>>
>> Sykora Data Center s.r.o.
>> 28. října 1512/123, 702 00 Ostrava
>> www.sykora.cz <http://www.sykora.cz>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> --
>
> *Ing. Vladimír Martinek*
> Programmer
>
> T: +420 723 908 968
> @: vm(a)sykora.cz <mailto:vm@sykora.cz>
>
> Sykora Data Center s.r.o.
> 28. října 1512/123, 702 00 Ostrava
> www.sykora.cz <http://www.sykora.cz>
>
--
*Ing. Vladimír Martinek*
Programmer
T: +420 723 908 968
@: vm(a)sykora.cz
Sykora Data Center s.r.o.
28. října 1512/123, 702 00 Ostrava
www.sykora.cz
8 years, 6 months
Relations are not loaded when using Fetch Profiles
by Vladimir Martinek
Fetch profiles fail to load certain relations because of invalid cycle
detection in MetamodelGraphWalker. Below is an example.
I have compared the behaviour of Fetch Profiles and standard EAGER
relations (EAGER does not suffer from this problem). The
MetamodelGraphWalker graph walker produces the same results, the SQL is
the same (missing relation).
With EAGER the relation is loaded in second pass, via
SessionImpl.internalLoad(). There it is decided what LoadType is used -
for eager it uses INTERNAL_LOAD_EAGER, for lazy INTERNAL_LOAD_LAZY. It
does not take into account the fetch profiles here!
The last place I can get hold of fetch profiles in in
AbstractLoadPlanBasedEntityLoader line 82. After that the fetch profile
information is lost, never making it anywhere near to
SessionImpl.internalLoad().
I would like to implement this, but to do that, I need someone to point
me in the right direction. Most of all I need answers to following
questions:
1) Is it right to assume the fetch profiles should be evaluated in
SessionImpl.internalLoad() and appropriate LoadType used when detected a
relation affected by a fetch profile?
2) If so, what is the intended way of getting the fetch profile
information to SessionImpl.internalLoad()?
Also, a colleague of mine attempted to implement FetchType.SELECT fetch
strategy and ended up with precisely the same problem. I believe solving
my issue would pave way for quick FetchType.SELECT implementation (which
we could also use on our project).
Thank you
Vladimir Martinek
Example:
Have 5 entities - Start, Via1, Via2, Mid and Finish with following
relations (all LAZY):
Start n:1 Via1 n:1 Mid n:1 Finish
Start n:1 Via2 n:1 Mid n:1 Finish
Now, trying to use Fetch Profiles to load Start entity and all of its
relations. I would expect Hibernate to execute following SQL select:
SELECT * FROM Start s
LEFT OUTER JOIN Via1 v1 (path Start-Via1)
LEFT OUTER JOIN Mid
JOIN Finish
LEFT OUTER JOIN Via2 (path Start-Via2)
LEFT OUTER JOIN Mid
JOIN Finish
Unfortunately, ii ompletely omits the second join from Mid to Finish,
what I am getting is:
SELECT * FROM Start s
LEFT OUTER JOIN Via1 v1 (path Start-Via1)
LEFT OUTER JOIN Mid
JOIN Finish
LEFT OUTER JOIN Via2 (path Start-Via2)
LEFT OUTER JOIN Mid
I dug deeper into this and found cycle detection in
MetamodelGraphWalker, line 144. Basically, when MetamodelGraphWalker
detects a relation that has already been visited, it considers it a
cycle. But in my case it is not a cycle - I just came to the same
relation twice using two different paths.
8 years, 6 months
Stream result change proposal
by Vlad Mihalcea
Hi,
While writing documentation for the new 5.2 Query.stream() API, I realized
that we don't return a Stream<T>, but a Stream<Object[]> which could
confuse users.
This is because ScrollableResultsImpl does something like this:
if ( result != null && result.getClass().isArray() ) {
currentRow = (Object[]) result;
}
else {
currentRow = new Object[] {result};
}
The result is the actual entity that we queries, while the currentRow
is an Object[].
I think we might want to change the stream result so that we return
the result for each available entry.
Vlad
8 years, 6 months
