Static update strings appear to cover only the following situations:
1) there are no uninitialized properties (so all updateable attributes
should be updated);
2) all lazy properties are uninitialized (so only
non-lazy, updateable attributes should be updated).
As of 5.1, we have "lazy groups". It
Please do not push anything to master branch.
Thanks,
Andrea
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
For details:
http://in.relation.to/2016/10/26/hibernate-orm-524-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Hi all,
there's a conflict in the Javassist versions of the WildFly modules of
Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not
familiar with this functionality.
The module declares *both*:
- a dependency to the WildFly provided Javassist:
- inclusion of Hibernate's own ve
Would be interesting to know why JipiJapa is depending on it. In a quick
search I couldn't spot any actual usages.
JPADependencyProcessor adds a dependency to "org.javassist", maybe that
could be avoided by having the ORM module re-export the version of JipiJipa
it is using? For that he module ZIP
Just to be clear, Jipijapa doesn't use Javassist at all. For JPA
deployments that are using Hibernate, the (WildFly) JPA container is
exporting the org.javassist:module to the application deployment
classloader, so that the Javassist proxy runtime classes can be
referenced by application classes t
Hi,
2016-10-27 0:44 GMT+02:00 Scott Marlow :
> Just to be clear, Jipijapa doesn't use Javassist at all.
Ok. What is the reason then that it is declaring this module dependency?
> For JPA
> deployments that are using Hibernate, the (WildFly) JPA container is
> exporting the org.javassist:mod
On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling wrote:
> Hi,
>
> 2016-10-27 0:44 GMT+02:00 Scott Marlow :
>>
>> Just to be clear, Jipijapa doesn't use Javassist at all.
>
>
> Ok. What is the reason then that it is declaring this module dependency?
No reason, looks like an unneeded dependency that
On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow wrote:
> On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling
> wrote:
> > Couldn't this be achieved by having the ORM module re-export the
> Javassist
> > module it depends on (in the module.xml of ORM, that is)?
> >
> >
> >
> > That way JipiJapa wou
> Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
(the WF module) export Javassist. Not the application.
>
I agree, that is what our WF pull request did, which I think is an
incremental improvement but that wasn't approved for the reason I gave.
>> Is the ORM testsuite b
10 matches
Mail list logo
