airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Christie (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-2872) registry-refactoring: OpenJPA doesn't persist setting a field to null
Date Thu, 30 Aug 2018 20:05:00 GMT


Marcus Christie commented on AIRAVATA-2872:

OpenJPA docs on attaching with null values:
When attaching null fields in these cases, OpenJPA cannot distinguish between a field that
was unloaded and one that was intentionally set to null. In this case, OpenJPA will use the
current detach state setting to determine how to handle null fields: fields that would have
been included in the detached state are treated as loaded, and will in turn set the corresponding
attached field to null.

"Detach state" options are
1. loaded: Detach all fields and relations that are already loaded, but don't include unloaded
fields in the detached graph. This is the default.
2. fetch-groups: Detach all fields and relations in the current fetch configuration. For more
information on custom fetch groups, see Section 7, “ Fetch Groups ”.
3. all: Detach all fields and relations. Be very careful when using this mode; if you have
a highly-connected domain model, you could end up bringing every object in the database into


Looks like #3, *all*, is what we want. I don't think the warning is applicable since we don't
explicitly detach the entities, instead we translate them to Thrift data model instances.
 I'll test this and see if it works.

> 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