Re: [hibernate-dev] Search - HSEARCH-1580 - Dependency graph
by Guillaume Smet
Hi Hardy,
Thanks for your feedback. I'll see what I can do next week about it.
--
Guillaume
On Fri, Jul 25, 2014 at 9:12 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> Hi,
>
> took a while to respond, but I tend to agree that @ContainedIn would be good enough.
> I don’t think a new annotation would make things clearer. As discussed before, the main
> issue was that the original intention was that @ContainedIn always requires an @IndexedEmbedded.
> It just happened to work also without and during the refactoring the behaviour was changed to
> match the original intentions.
>
> The important thing is to make sure that the documentation and javadocs are documenting the
> behaviour properly and consistently.
>
> So +1 for getting the old behaviour back
>
> —Hardy
>
>
>
>
>
> On 20 Jan 2014, at 11:08, Guillaume Smet <guillaume.smet(a)hibernate.org> wrote:
>
>> Hi,
>>
>> Following the discussion about releasing 5 sooner rather than later, I
>> wanted to point out that we still have to take a decision about
>> HSEARCH-1580:
>> - either commit in 5 the fix we committed to 4.x and update the documentation;
>> - or work on defining another concept.
>>
>> I don't have a strong opinion about what we should do but I have a
>> strong one about doing something before we release 5 :).
>>
>> References:
>> https://hibernate.atlassian.net/browse/HSEARCH-1580
>> https://hibernate.atlassian.net/browse/HSEARCH-1573
>>
>> Feedback welcome.
>>
>> (sorry for the long silence - busy months...)
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
10 years, 11 months
Native query and auto-flush
by Guillaume Smet
Hi!
Starting with HHH-8487, when we execute a native query, an auto-flush
is executed (and might be limited with addSynchronizedEntityClass and
allegates).
While I understand the rationale of this change, we are having a few
issues with this when the transaction opened is read-only which is the
case for all our read-only queries: Hibernate tries to flush the dirty
entities in a read-only transaction and fails.
The heart of the issue here is that we have dirty entities which
shouldn't be dirty (see my post on embedded and dirtiness) but I'm
wondering if it's a behavior which was missed by this patch or
something intentional. So I thought I might as well report it.
--
Guillaume
10 years, 11 months
HHH-7610 Embedded: emptiness and dirtiness
by Guillaume Smet
Hi all,
So, after a long time without any issue (rest assured we were busy
anyway!), we got around a new problem we would like to fix in ORM:
HHH-7610 .
It's a long standing complaint about the embedded and the fact that
empty components are returned from the ORM.
We had the "good" idea to fix it by overriding the getter to set the
value to an empty object if null and it's not really a good one: we do
a lot of unnecessary updates due to the fact that our entities are
considered dirty.
A coworker of mine (Laurent CCed) followed the instructions given by
Steve in HHH-7610 to implement a configuration setting to return an
empty component if all its properties is null:
see https://github.com/openwide-java/hibernate-orm/commit/a219fd38c0a80e6bf0a...
-> we think this one should be ready to commit. It's for 4.3.x.
-> using all the tests with this new setting enabled triggers a few
errors but, after carefully reviewing them, they are all expected due
to the nature of this change.
We are wondering if we shouldn't also change the isDirty/equals...
stuff to consider 2 components equals if one is null and the other has
all its properties null: it sounds kinda logical to us considering ORM
already automatically transforms one to the other if we save then get
the entity.
We wrote a few tests to demonstrate the issue and we would like to
know if you would consider this a good idea or not to fix this in both
cases (settings on or off):
https://github.com/openwide-java/hibernate-orm/commit/ee913e79633d3a5ac9c...
Thanks for your advice.
--
Guillaume
11 years
Get JSON value from Postgres
by Adriano Santos
Hi, everyone.
I'm trying to get a JSON value from Postgres DB, but I'm receiving this
error:
DefaultLoadEventListener:160 - Error performing load command
org.hibernate.PropertyAccessException: could not set a field value by
reflection setter of DTO.Processo._tramites
at
org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:151)
I saw that Hipernate don’t have a JSON Type yet, so I build a type for this.
I did a “My UserType” (StringJsonUserType implements UserType) and
JsonPostgreSQLDialect (extends PostgresPlusDialect). I insert data , but
when I try to get some value, i got this error return.
I using Hibernat version 3.5.6.final and postgresql-9.3-1102-jdbc.
Anybody have some idea about whats happen and can I workaround this problem?
Best regards.
--
Adriano Araújo Santos
*"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
original."*
11 years
Tests on JDK 9, and other updates on ci.hibernate.org
by Sanne Grinovero
Hi all,
I've installed latest preview builds of:
- JDK 9 b28
- JDK 8u40 b04
Java 9 is new in our builds, so some considerations:
- The JVM option MaxPermSize, which was deprecated in Java8, is no
longer accepted and will fail bootstrap. Either you remove it from
your build path or enable -XX:+IgnoreUnrecognizedVMOptions
- asciidoctor-maven-plugin plugin fails: I'll disable it for now but
it would be great if someone could have a look at it, if it's a JVM
bug we should report it, and otherwise fixing the plugin would be
nice.
On Java 8, a warning:
I've not simply added this beta, but it replaces the current one we
had setup. I realize this is a rather aggressive move, but keep in
mind the current one wasn't a stable release but an early preview as
well.
I guess we might want to split this into a "JDK 8" and a "JDK
8-preview" ? But even our current JDK8 builds are still largely
failing, so I'd rather see some love on that first, then we can move
on into multiple builds.
I would love some help on:
- the animal-sniffer is still broken on Java 8, see what can be done
or let's discuss alternatives
- Some ORM tests are failing on Java8
- Define JDK 9 test builds for more projects:
http://ci.hibernate.org/view/JDK9/
Cheers,
Sanne
11 years
[OGM] Removing row keys from associations
by Gunnar Morling
Hi Emmanuel,
Is there any legitimate case where Association#remove(RowKey) is invoked
for a key which is not present in that specific association instance? Or
would this indicate some programming error?
Thanks,
--Gunnar
11 years
Improving performance of index-writing for Hibernate Search
by Sanne Grinovero
Hi all,
after some performance tests on Infinispan we concluded that the way
Hibernate Search writes to the index is not as efficient as we'd like
to.
While these results came from extensive Infinispan testing, it's
actually highlighting a performance issue which isn't strictly related
to Infinispan storage, and could affect any kind of index storage
which we support.
Surprisingly this wasn't too bad for normal disk based FSDirectory,
especially as we expect users to got for the NRT backend, but as you
might know an NRT backend is not suited for clustered deployments (be
it using a master/slave approach or the Infinispan index, or other
more experimental shared index strategies like NFS based sharing).
So, while NRT performs great, the "normal" backend actually doesn't
perform very well because of the high frequency of commits.
Surprisingly even an ASYNC backend does the same amount of commits, so
enabling the async workers of Hibernate Search would decouple the
latency of the main thread from the speed of the backend, but if you
have a sustained amount of writes the overall throughput that the
backend is able to deliver would not change.
A much better design is to allow the ASYNC backends to _not_ flush at
each commit, but to flush periodically. The overall throughput
increase is estimated to be 2 to 3 orders of magnitude, details
depending on the kind of storage you're having.
This idea is being proposed as:
- https://hibernate.atlassian.net/browse/HSEARCH-1693
Gustavo sent a first pull request for this already, some preliminary
results can be found on the pull request description:
https://github.com/hibernate/hibernate-search/pull/681
Note that his tests focus on Infinispan storage but the code is
unrelated to Infinispan and will benefit all users independently from
the storage technology.
This patch will expose a new configuration property which will allow
users to specify how often they need the indexes to be committed; in
other words, you'll be able to specify that Async is acceptable for
your application, but as long as the "staleness" of your index doesn't
exceed a set threshold of time.
Now the best part of this, is that we can also propose a solution for
the SYNC backends which require an illusion of transactional
behaviour. Essentially we're aiming at implementing a synchronous
backend which has performance close to the capabilities of NRT, but
without the drawbacks so that it can safely be used on shared indexes.
This ideas is a bit more complex to implement, I've attempted to describe it on:
https://hibernate.atlassian.net/browse/HSEARCH-1699
Sanne
11 years
