Hibernate invkoing onFlushDirty for umodified objects in Set
by Nitin G. Prabhu
Hi All,
I have a object with below relationship
public class A {
@Id
@SequenceGenerator(name = "ID_GENERATOR", sequenceName = "Id_SEQ", allocationSize = 1)
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "ID_GENERATOR")
@Column(name = "id")
private BigDecimal id;
@OneToMany(mappedBy = MST, orphanRemoval = true, cascade = { CascadeType.ALL})
@OrderBy("id DESC")
private List<B> b = new ArrayList<B>();
@Column(name = "name")
private String name;
}
When I modify class A'S SAY name attribute and say dao.persist(A) then onFlushDirty()[overridden in my Hibernate interceptor] is also invoked even if B object is not modified
I am not understanding why hibernate is treating List<B> objects to be dirty when I am trying to save the parent object A
Regards,
Nitin
MASTEK LTD.
In the US, we're called MAJESCOMASTEK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10 years, 10 months
ORM build - IDE imports
by Steve Ebersole
I have been thinking of ways to make importing ORM into IDE more
transparent. My thinking is from the IntelliJ pov and the specific issues
I have run into there. I wanted to run my thoughts past y'all to see if
they helped with Eclipse and/or other IDEs.
-----
The main thing I see is trouble with the generated-src dir. IntelliJ
automatically "excludes" the build directory which is actually perfect,
generally speaking. However, we put generated-src under the build dir so
it gets excluded by extension as well. That's why after import we need to
adjust excluded dirs and source dirs. My suggestion here is to move
generated-src out from under the build dir, making it on level with src and
target. So we'd have:
{projectRoot}
+- generated-src
+- src
\- target
generated-src and target would both be directories that are created by the
build and are git-ignored. The point being that IntelliJ would still
exclude target as the main build dir, but generated-src is no longer under
that dir and would not be excluded. In my experience the import marks the
generated source dirs properly other than them being transitively excluded.
----
A related issue is the execution of source generators. This has already
been partially been addressed. Today we have a split between:
1) source generators that generate sources required at compile time (antlr,
jaxb, jpa-metamodel-gen, etc)
2) source generators that generate sources required at run time (currently
only logging).
There is also a concern here between AP-based generators and non-AP-based
generators. And unfortunately they split across the compile/run time
requirement. I am not really sure of an ideal solution here. And the
situation is compounded by the fact that IntelliJ won't let us apply
annotation processors to its compile process because of the
hibernate-testing module circularity :(
To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as the
best-case scenario. But that is not likely to happen soon. And coupled
with the fact of the IntelliJ limitation due to hibernate-testing
circularity, I am not sure it would practically help.
It seems to me the only real option currently is to expect a full compile
prior to import.
Better suggestions?
----
Speaking of the hibernate-testing circularity, I do still want to get rid
of that. Currently I have been waiting on Gradle adding support for
publishing multiple artifacts from a project (module). The idea being that
we'd fold the source from hibernate-testing into hibernate-core and have
hibernate-core produce and publish both artifacts. Currently Gradle only
supports a single publication from a project. So the hang up really is
publishing hibernate-testing to nexus. I think we all agreed last time
this was discussed that publishing hibernate-testing to nexus was important
enough to hold off on. Do I remember that correctly? Is that still the
situation?
10 years, 10 months
in.relation.to fixed
by Sanne Grinovero
All,
the blog platform finally finished its migration to the new servers.
If you still see errors, please let us know as that would be a new problem.
Sanne
10 years, 10 months
Re: [hibernate-dev] Jira + pull requests
by Sanne Grinovero
Because the automated integration doesn't work at all if you rebase.
I've considered disabling that JIRA plugin.. for now I'm hoping it
will improve in future.
On 6 November 2014 15:26, Hardy <hibernate(a)ferentschik.de> wrote:
> OOI, why do you still add the pull request links manually to Jira. It's
> nicely and automatically integrated anyways.
>
> -- hardy
>
>
10 years, 10 months
