Multi-table Bulk Operations with Temporary Tables
by Łukasz Antoniak
Hello all!
I have just a very short question regarding concurrency aspects when temporary tables are utilized to process multi-table bulk
operations. I am trying to refactor part of Envers code which currently executes SELECT FOR UPDATE and UPDATE, to process with a
single UPDATE statement. The root cause is that Hibernate produces invalid SQL query with UPGRADE lock for inheritance mappings on
Oracle, PostgreSQL and SQL Server (HHH-3298). UPDATE statement should modify only one row. For updating inheritance relation
Hibernate uses temporary table:
14:52:01,687 DEBUG SQL:104 - insert into HT_ParentEntity_AUD select parententi0_.id as id, parententi0_.REV as REV from ( select
id, REV, REVTYPE, REVEND, data, null as numVal, 0 as clazz_ from ParentEntity_AUD union all select id, REV, REVTYPE, REVEND, data,
numVal, 1 as clazz_ from ChildEntity_AUD ) parententi0_ where parententi0_.id=? and (parententi0_.REVEND is null) and
parententi0_.REV<>?
14:52:01,781 DEBUG SQL:104 - update ParentEntity_AUD set REVEND=? where (id, REV) IN (select id, REV from HT_ParentEntity_AUD)
14:52:01,796 DEBUG SQL:104 - delete from HT_ParentEntity_AUD
Questions:
1. What occurs when two different sessions try updating same data? When temporary table is begin created (I cannot see it in the
standard output)? Assuming that it is created just before "insert into HT_ParentEntity_AUD ...", the second session that executes
this statement should fail. Am I right?
2. Would my modification affect performance? Currently Envers executes:
22:04:02,734 DEBUG SQL:104 - select parententi0_.id as id12_, parententi0_.REV as REV12_, parententi0_.REVTYPE as REVTYPE12_,
parententi0_.REVEND as REVEND12_, parententi0_.data as data12_, parententi0_.numVal as numVal13_, parententi0_.clazz_ as clazz_
from ( select id, REV, REVTYPE, REVEND, data, null as numVal, 0 as clazz_ from ParentEntity_AUD union all select id, REV, REVTYPE,
REVEND, data, numVal, 1 as clazz_ from ChildEntity_AUD ) parententi0_ where parententi0_.id=? and (parententi0_.REVEND is null)
for update
22:04:02,750 DEBUG SQL:104 - update ParentEntity_AUD set REVEND=? where id=? and REV=?
I'm not sure if creating temporary table, inserting data and then removing it is the right thing for updating just one record.
Regards,
Lukasz
12 years, 7 months
Re: [hibernate-dev] Interceptor question
by Emmanuel Bernard
The reason I did map manual indexing to apply default is that I sided with Sanne s reasoning and I went on the side of caution with the API. I'd love to get more practical feedback before deciding to either:
- stay as it is
- map indexing and purge to the interceptor - I don't think we can safely map purge all
- add two methods to the interceptor to treat index and purge explicitly
Emmanuel
On 11 mai 2012, at 17:45, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
> Really? I would argue differently.
>
> Let's take the blog example where I only want to index blog entries which are
> published. Adding the interceptor and relying on automatic indexing will not index un-published entries. Great.
> If I, however, want/ have to re-index my blog entries via the API the interceptor does not apply? Why?
>
> IMO the interceptor has to apply for automatic index updates as well as explicit index request. Conceptually
> (for a user) there is no difference between explicitly calling FulltextSession#index or auto-indexing. That's
> exactly the type of confusion the user on the forum experienced.
>
> I think we should change this behavior.
>
> --Hardy
>
>
> On May 11, 2012, at 5:23 PM, Sanne Grinovero wrote:
>
>> As a user if I were asking to Search *explicitly* to index my entity,
>> I would not be pleased in the framework to override my request... I
>> think the code is correct, maybe it's worth pointing this out at least
>> on #index() javadoc?
>>
>> Sanne
>>
>> On 11 May 2012 14:48, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
>>> Hi,
>>>
>>> quick question regarding the indexing interceptor. Why is WorkType.Index mapped to IndexingOverride.APPLY_DEFAULT -
>>> https://github.com/hferentschik/hibernate-search/blob/master/hibernate-se...
>>>
>>> Shouldn't it be the same as ADD? Am I missing something? I am asking, because of https://forum.hibernate.org/viewtopic.php?f=9&t=1015173
>>>
>>> --Hardy
>
12 years, 7 months
Absolute path to hibernate.cfg.xml
by Dmitry Geraskov
Hi, guys,
it is possible to set in persistence.xml path to hibernate.cfg.xml. The
question is: can this path be absolute and work? Or the path must be
classpath relative?
This question is important for our plugins ui.
Thanks, Dmitry
12 years, 7 months
[SEARCH] @Indexed on abstract classes
by Guillaume Smet
Hi Search team,
I have this question for a long time but, this time, having 30 (and
growing) indexed entities inheriting from an abstract class, I thought
I might as well ask about it...
Is there any reason why we can't set the @Indexed annotation on the
abstract class to get all the implementations indexed in their
separate indexes? This way, I wouldn't have to put the annotation on
each implementation and think about adding it each time I extend this
abstract class.
Another painful things that beats me yesterday is that I cannot do:
searchFactory.buildQueryBuilder().forEntity(MyAbstractEntity.class).get();
to build Lucene queries based on the common indexed fields of the
abstract class: I'm forced to use one of the concrete implementation
(and apart that it's not that nice, I'm not that confident I can
choose one that will never be removed from the code base).
Thanks for your feedback.
--
Guillaume
12 years, 7 months
Re: [hibernate-dev] Interceptor question
by Hardy Ferentschik
Really? I would argue differently.
Let's take the blog example where I only want to index blog entries which are
published. Adding the interceptor and relying on automatic indexing will not index un-published entries. Great.
If I, however, want/ have to re-index my blog entries via the API the interceptor does not apply? Why?
IMO the interceptor has to apply for automatic index updates as well as explicit index request. Conceptually
(for a user) there is no difference between explicitly calling FulltextSession#index or auto-indexing. That's
exactly the type of confusion the user on the forum experienced.
I think we should change this behavior.
--Hardy
On May 11, 2012, at 5:23 PM, Sanne Grinovero wrote:
> As a user if I were asking to Search *explicitly* to index my entity,
> I would not be pleased in the framework to override my request... I
> think the code is correct, maybe it's worth pointing this out at least
> on #index() javadoc?
>
> Sanne
>
> On 11 May 2012 14:48, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
>> Hi,
>>
>> quick question regarding the indexing interceptor. Why is WorkType.Index mapped to IndexingOverride.APPLY_DEFAULT -
>> https://github.com/hferentschik/hibernate-search/blob/master/hibernate-se...
>>
>> Shouldn't it be the same as ADD? Am I missing something? I am asking, because of https://forum.hibernate.org/viewtopic.php?f=9&t=1015173
>>
>> --Hardy
12 years, 7 months
Re: [hibernate-dev] [HV] Implementing method validation (was "HV-562")
by Gunnar Morling
Am 10.05.2012 15:01 schrieb "Hardy Ferentschik" <hardy(a)hibernate.org>:
>
>
> > nice post on the release, this should get started everyone with 4.3.
> > And we can finally focus on HV 5 :)
>
> thanks :-)
>
> >
> >>> I'm looking forward to implementing the new API, this should be
> >>> fun :) I feel that it should be possible to split the work into
> >>> independent chunks which we can tackle in parallel.
> >>
> >> That sounds good. In a first cut we might be able to just try to
compile the latest BV SNAPSHOT and introduce the missing
> >> methods by introducing placeholders. Once the existing build passes
again we can already push a SNAPSHOT and start
> >> filling in the gaps.
> >
> > I've created a branch for method validation [1], bumped the dependency
> > to the BV API to 1.1.Alpha1 and applied the minimal changes required
> > to get rid of any compilation errors (added
> > UnsupportedOperationExceptions within the new methods). I've also
> > added "TODO HV-571" markers everywhere, so we can't forget everything
> > :)
>
> Awesome. I was planning to do this, but since you already got started …
:-)
> Personally I don't like working on branches. Instead I would like to
continue working on master.
> I took your branch and used the TestNG suite files to exclude the failing
tests in
> engine and tck-runner. Have a look at
https://github.com/hferentschik/hibernate-validator/commits/HV-571
That looks good. Quite a number of tests which are concerned :)
>
> What do you think about pushing this to master. As we develop the missing
features we just
> re-enable things.
So far we've always developed new features on individual branches (within
our forked repos) and had them pulled into master afterwards. That way
master was always relatively stable and had a good quality.
This would change if we integrate individual changes of the method
validation work into master. IMO this wouldn't be a problem per se, as long
as we only work on HV-571. But we might get problems if we decide to work
on further, unrelated issues in parallel. For instance we wouldn't
recognize that such a change causes one of the tests disabled for HV-571 to
fail.
I think the new situation is that more than one person is working on the
same feature. Have there been similar cases in Search etc.? How was it
handled there? Personally I think a HV-571 feature branch in the master
repo would be a good thing to integrate and stabilize our work, leaving the
opportunity to work on other things as well, should that need arise. Also
it shouldn't necessarily be more complex than pushing to master (at least
as long as there isn't too much other traffic on master).
>
> > Regarding the actual implementation, I think there are two large
> > blocks, which might be addressed in parallel: a) implementing the new
> > validation methods and b) implementing the extensions to the meta data
> > API (plus some other things such as changes to ConfigurationImpl
> > etc.).
>
> +1 I could for example look into some some the metadata stuff. But in the
end I would leave it
> to you to take whatever you like.
Sounds good to me, then I'll start with the validation methods.
> I will then take the slack. Let's just
> make sure we are in sync what we are doing.
+1. I think I'll start tomorrow. Regarding the current proprietary API, I
see no way we can keep it, as for instance there are methods in the BV API
with same names but with different return types. So I think we should
remove it completely. WDYT?
>
> --Hardy
>
--Gunnar
12 years, 7 months
[HV] Implementing method validation (was "HV-562")
by Gunnar Morling
Hi Hardy,
nice post on the release, this should get started everyone with 4.3.
And we can finally focus on HV 5 :)
>> I'm looking forward to implementing the new API, this should be
>> fun :) I feel that it should be possible to split the work into
>> independent chunks which we can tackle in parallel.
>
> That sounds good. In a first cut we might be able to just try to compile the latest BV SNAPSHOT and introduce the missing
> methods by introducing placeholders. Once the existing build passes again we can already push a SNAPSHOT and start
> filling in the gaps.
I've created a branch for method validation [1], bumped the dependency
to the BV API to 1.1.Alpha1 and applied the minimal changes required
to get rid of any compilation errors (added
UnsupportedOperationExceptions within the new methods). I've also
added "TODO HV-571" markers everywhere, so we can't forget everything
:)
Regarding the actual implementation, I think there are two large
blocks, which might be addressed in parallel: a) implementing the new
validation methods and b) implementing the extensions to the meta data
API (plus some other things such as changes to ConfigurationImpl
etc.).
If we decide to work on this in parallel, we might push the HV-571
feature branch to the upstream repo, integrate the method validation
work there and push it later on in one go to master.
WDYT, would that make sense?
--Gunnar
[1] https://github.com/gunnarmorling/hibernate-validator/compare/HV-571
12 years, 7 months
ORM 4.1.3 release announcement?
by Guillaume Smet
Hi,
While 4.1.3 was released some time ago, I haven't seen any
announcement for that on either the Hibernate website or the list.
Is there a reason for that? It contains very valuable bugfixes
(especially on the NaturalId front) that might be of interest for a
lot of users, which are not as JIRA addicted as I am.
I thought it might be an overlook. Feel free to ignore this message if
you have better things to do :).
Btw, thanks for this release which fixes all the problems we had with
the new NaturalId API/cache on our project.
--
Guillaume
12 years, 7 months
[HSEARCH] Proposal to change the default value of Field#norms()
by Andrej Golovnin
Hi all,
the default value of norms() in the Field annotation is defined to YES.
I doubt it is always needed, e.g. if you have an Enum field, do you really
need norms for it? The same applies to long/int, boolean, date, OID fields
and very short fields like a code of the country.
I have already asked Sanne on the chat what was the motivation
to set it per default to YES. And he responded that the main reason is
backwards compatibility, i.e. it has always been enabled.
I'm now analyzing our program and I see absolutely no need for norms
(we are in process to switch from Hibernate Search 3.0.1 to the latest one).
But changing it for every field is a really huge task as we have a big application.
To improve the performance and to reduce memory consumption I would
like to change the default value of Field#norms() from YES to NO because
it has impact on the performance and memory consumption.
And users of Hibernate Search should decide per field if they really need
norms or not, e.g. if they want to do advanced queries, then they can activate
the norms for such fields.
I know this would break backwards compatibility. But I think in this case it
is a good thing.
Sanne also suggested an alternative solution. We may introduce a new global
option which would define the default value for Field#norms(). The default
value of this option would be obviously YES. Users like me could change it
to NO if needed. I personally think we have already enough options. But
this solution would be OK for me.
What do you think?
Best regards,
Andrej Golovnin
12 years, 7 months
