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
>
11 years, 2 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
11 years, 2 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, 2 months
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, 2 months
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, 2 months
[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, 2 months
