PM - Simple vs. Bundle - mixin removal handling

[Jan Haderka]

Hi,

I have a question about purpose of perceived difference in handling
mixins when using Simple or Bundled PM.

Following code (assuming node had mixin mix:versionable before):
    node.removeMixin("mix:versionable");
    node.save();
leads to difference in stored data based on PM used.
If you perform the operation above and restart your repository
call to:
    node.isMixinType("mix:versionable");
will return false after restart in both cases, but
doing:
hasMixin(node, "mix:versionable");
will return true when repository is using bundled PM. The hasMixin()
method just iterates over all values of jcr:mixinTypes property:

public static void hasMixin(Node node, String mixin) {
  try {
    Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
    for (int i = 0; i < vals.length; i++) {
      log.debug(vals[i].getString());
      if (mixin.equals(vals[i].getString())) {
        return true;
      }
    }
  } catch (PathNotFoundException e) {
    // property not found == can't contain anything
    return false;
  }
  return false;
}

I think the difference is caused by following code (JR 1.4.5) in
AbstractBundledPersistenceManager (which doesn't seem to have equivalent
in simple PM)

557                // skip primaryType pr mixinTypes properties
558                if (id.getName().equals(QName.JCR_PRIMARYTYPE)
559                    || id.getName().equals(QName.JCR_MIXINTYPES)
560                    || id.getName().equals(QName.JCR_UUID)) {
561                    continue;
562                }

I'm not sure whether it is a bug or not, it doesn't seem to have any
side effects.
Can someone explain to me what is the reason for skipping primary and
mixin types property changes when persisting nodes?

In case it is relevant: I discovered & tested this while working with
Derby bundle & simple PM and using JR 1.4.5

Thanks,
Jan

[Stefan Guggisberg-2]

hi jan

On Wed, Jul 23, 2008 at 5:10 PM, Jan Haderka <jan.haderka@...> wrote:

> Hi,
>
> I have a question about purpose of perceived difference in handling
> mixins when using Simple or Bundled PM.
>
> Following code (assuming node had mixin mix:versionable before):
>    node.removeMixin("mix:versionable");
>    node.save();
> leads to difference in stored data based on PM used.
> If you perform the operation above and restart your repository
> call to:
>    node.isMixinType("mix:versionable");
> will return false after restart in both cases, but
> doing:
> hasMixin(node, "mix:versionable");
> will return true when repository is using bundled PM. The hasMixin()
> method just iterates over all values of jcr:mixinTypes property:
>
> public static void hasMixin(Node node, String mixin) {
>  try {
>    Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
>    for (int i = 0; i < vals.length; i++) {
>      log.debug(vals[i].getString());
>      if (mixin.equals(vals[i].getString())) {
>        return true;
>      }
>    }
>  } catch (PathNotFoundException e) {
>    // property not found == can't contain anything
>    return false;
>  }
>  return false;
> }
>
> I think the difference is caused by following code (JR 1.4.5) in
> AbstractBundledPersistenceManager (which doesn't seem to have equivalent
> in simple PM)
>
> 557                // skip primaryType pr mixinTypes properties
> 558                if (id.getName().equals(QName.JCR_PRIMARYTYPE)
> 559                    || id.getName().equals(QName.JCR_MIXINTYPES)
> 560                    || id.getName().equals(QName.JCR_UUID)) {
> 561                    continue;
> 562                }
>
> I'm not sure whether it is a bug or not, it doesn't seem to have any
> side effects.

it's a bug. thanks for your detailed analysis!
could please create a jira issue?

thanks
stefan

> Can someone explain to me what is the reason for skipping primary and
> mixin types property changes when persisting nodes?
>
> In case it is relevant: I discovered & tested this while working with
> Derby bundle & simple PM and using JR 1.4.5
>
> Thanks,
> Jan
>
>
>

[Jan Haderka]

> it's a bug. thanks for your detailed analysis!
> could please create a jira issue?
>

You're welcome. :)
Reported on jira as https://issues.apache.org/jira/browse/JCR-1690

Cheers,
Jan

[Marcel Reutegger]

Hi,

not sure, but I think this has already been reported before. this issue looks
very similar:

https://issues.apache.org/jira/browse/JCR-1632

regards
  marcel

Jan Haderka wrote:

>> it's a bug. thanks for your detailed analysis!
>> could please create a jira issue?
>>
>
> You're welcome. :)
> Reported on jira as https://issues.apache.org/jira/browse/JCR-1690
>
> Cheers,
> Jan
>
>

[Stefan Guggisberg-2]

On Thu, Jul 24, 2008 at 9:59 AM, Marcel Reutegger
<marcel.reutegger@...> wrote:
> Hi,
>
> not sure, but I think this has already been reported before. this issue
> looks very similar:
>
> https://issues.apache.org/jira/browse/JCR-1632

right, i agree. it's the same problem:

there's a bug in AbstractBundlePersistenceManager which may lead
to jcr:mixinTypes properties not reflecting the actual set of assigned
mixin types.

cheers
stefan

>
> regards
>  marcel
>
> Jan Haderka wrote:
>>>
>>> it's a bug. thanks for your detailed analysis!
>>> could please create a jira issue?
>>>
>>
>> You're welcome. :)
>> Reported on jira as https://issues.apache.org/jira/browse/JCR-1690
>>
>> Cheers,
>> Jan
>>
>>
>
>