airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-2872) registry-refactoring: OpenJPA doesn't persist setting a field to null
Date Tue, 06 Nov 2018 16:48:00 GMT


ASF subversion and git services commented on AIRAVATA-2872:

Commit f4b61a7614c51f0eb0c7cc0406e1746327bc64c7 in airavata's branch refs/heads/develop from
[;h=f4b61a7 ]

AIRAVATA-2872 Allow setting resourceSpecificCredStoreToken to null

Changed the "detach state" setting in OpenJPA to "all" which changes how
null values are merged. Without "all", null values are treated as simply
unspecified and are not merged in. With "all", null values are treated
as specified values that are merged in.

One consequence is that any field on the JPA entities that isn't in the
Thrift models OpenJPA will attempt to set it to null. For this reason,
@ManyToOne references, which aren't in the Thrift models, are configured
so that the @JoinColumn is not nullable and not updateable, which is
true regardless but is necessary now with the change in "detach state"

I also set up orphanRemoval on the GroupResourceProfileEntity to test
that that would still work as well.

> registry-refactoring: OpenJPA doesn't persist setting a field to null
> ---------------------------------------------------------------------
>                 Key: AIRAVATA-2872
>                 URL:
>             Project: Airavata
>          Issue Type: Bug
>          Components: Registry API
>            Reporter: Marcus Christie
>            Assignee: Marcus Christie
>            Priority: Major
> In OpenJPA, the default handling of null values on detached instances is to treat them
as "unloaded" when merging them, meaning it treats them as if they are simply missing instead
of treating them as having been set to null. That is, it skips over null value and doesn't
update the corresponding fields on the persistent instances to have a null value.
> See
> See also official docs:,
however it's hard to understand how to make use of this in our context.
> See also this discussion
> I traced the OpenJPA code to these lines in VersionAttachStrategy:
> {code:java}
>         int detach = (isNew) ? DETACH_ALL : broker.getDetachState();
>         FetchConfiguration fetch = broker.getFetchConfiguration();
>         try {
>             FieldMetaData[] fmds = sm.getMetaData().getFields(); 
>             for (int i = 0; i < fmds.length; i++) {
>                 switch (detach) {
>                     case DETACH_ALL:
>                         attachField(manager, toAttach, sm, fmds[i], true);
>                         break;
>                     case DETACH_FETCH_GROUPS:
>                         if (fetch.requiresFetch(fmds[i]) 
>                             != FetchConfiguration.FETCH_NONE)
>                             attachField(manager, toAttach, sm, fmds[i], true);
>                         break;
>                     case DETACH_LOADED:
>                         attachField(manager, toAttach, sm, fmds[i], false);
>                         break;
>                 }
>             }
>         } finally {
> {code}
> The detach state is {{DETACH_LOADED}} which causes OpenJPA to treat nulls as unloaded
and thus it skips merging those values in.
> I think with a configuration change we can get this to work, but it's not obvious what
all the flags mean, so this will take some research.
> One other question I have, is how did this work before. It would be worth checking to
see how the old registry code had configured OpenJPA.

This message was sent by Atlassian JIRA

View raw message