behavior of jcr:lastModified in jackrabbit 2.0

[Tobias Bocanegra <to...@day.com>]

hi,
the spec of JSR283 defines a new mixin node type:

[mix:lastModified] mixin
  - jcr:lastModified (DATE) protected? OPV?
  - jcr:lastModifiedBy (STRING) protected? OPV?

"This mixin node type can be used to provide standardized modification
information properties to a node. Since the properties are protected,
their values
are controlled by the repository, which should set them appropriately upon a
significant modification of the subgraph of a node with this mixin. What
constitutes a significant modification will depend on the semantics of
the various
parts of a node's subgraph and is implementation-dependent."

Since the "protected" attributes are variant, we can implement them as we wish.
i would like to have a "good" jcr:lastModified behavior that is
directly provided by the repository.
OTOH when dealing with files (nt:file) uploaded from a filesystem, it
probably makes sense to transport the last-modified of the original
file.

we need to define:
1) does jackrabbit support automatic jcr:lastModified computation ?
2) if yes, do we make it protected ?
3) what operations on which scope affect which jcr:lastModified properties
4) does changing the jcr:lastModified property trigger an observation event?

at a first glance, i would say:
1) yes, please support it
2) no, keep it writable
3) all changes (except versioning and import operations) in an
mix:lastModified aggregate affect it's last modified property. the
aggregate is defined as sub-tree below a mix:lastModified node,
without all other mix:lastModified sub-trees.
4) don't know - probably not

WDYT ?
regards, toby

Re: behavior of jcr:lastModified in jackrabbit 2.0

[Stefan Guggisberg <st...@gmail.com>]

hi tobi

On Wed, Jun 17, 2009 at 11:12 PM, Tobias
Bocanegra<to...@day.com> wrote:
> hi,
> the spec of JSR283 defines a new mixin node type:
>
> [mix:lastModified] mixin
>  - jcr:lastModified (DATE) protected? OPV?
>  - jcr:lastModifiedBy (STRING) protected? OPV?
>
> "This mixin node type can be used to provide standardized modification
> information properties to a node. Since the properties are protected,
> their values
> are controlled by the repository, which should set them appropriately upon a
> significant modification of the subgraph of a node with this mixin. What
> constitutes a significant modification will depend on the semantics of
> the various
> parts of a node's subgraph and is implementation-dependent."
>
> Since the "protected" attributes are variant, we can implement them as we wish.
> i would like to have a "good" jcr:lastModified behavior that is
> directly provided by the repository.
> OTOH when dealing with files (nt:file) uploaded from a filesystem, it
> probably makes sense to transport the last-modified of the original
> file.
>
> we need to define:
> 1) does jackrabbit support automatic jcr:lastModified computation ?

yes

> 2) if yes, do we make it protected ?

no

> 3) what operations on which scope affect which jcr:lastModified properties

i'd say all changes that trigger a nodestate modification of the
mix:lastModified node.

> 4) does changing the jcr:lastModified property trigger an observation event?

yes

cheers
stefan

>
> at a first glance, i would say:
> 1) yes, please support it
> 2) no, keep it writable
> 3) all changes (except versioning and import operations) in an
> mix:lastModified aggregate affect it's last modified property. the
> aggregate is defined as sub-tree below a mix:lastModified node,
> without all other mix:lastModified sub-trees.
> 4) don't know - probably not
>
> WDYT ?
> regards, toby
>

Re: behavior of jcr:lastModified in jackrabbit 2.0

[Marcel Reutegger <ma...@gmx.net>]

Hi,

2009/6/17 Tobias Bocanegra <to...@day.com>:
> we need to define:
> 1) does jackrabbit support automatic jcr:lastModified computation ?
> 2) if yes, do we make it protected ?
> 3) what operations on which scope affect which jcr:lastModified properties
> 4) does changing the jcr:lastModified property trigger an observation event?
>
> at a first glance, i would say:
> 1) yes, please support it

+1

> 2) no, keep it writable

agreed. this allows a client to overwrite the automatic update. I
think this is important for various use cases.

> 3) all changes (except versioning and import operations) in an
> mix:lastModified aggregate affect it's last modified property. the
> aggregate is defined as sub-tree below a mix:lastModified node,
> without all other mix:lastModified sub-trees.

not sure about this one. so any modification would need to walk up the
tree and check if there is a node with a mix:lastModified, right? that
might have an effect on backward compatibility. suppose you set a
property on a node and then call save on *that* node. what happens to
an ancestor with a modified jcr:lastModified triggered by that
modification? will it be saved as well? should the save fail?
Item.save() is deprecated, so we don't have to worry to much about
this case, but still...

> 4) don't know - probably not

I think it has to. all content changes must trigger observation
events. e.g. the index depends on events for updates.

regards
 marcel

Re: behavior of jcr:lastModified in jackrabbit 2.0

[Felix Meschberger <fm...@gmail.com>]

Hi,

Tobias Bocanegra schrieb:
> hi,
> the spec of JSR283 defines a new mixin node type:
> 
> [mix:lastModified] mixin
>   - jcr:lastModified (DATE) protected? OPV?
>   - jcr:lastModifiedBy (STRING) protected? OPV?
> 
> "This mixin node type can be used to provide standardized modification
> information properties to a node. Since the properties are protected,
> their values
> are controlled by the repository, which should set them appropriately upon a
> significant modification of the subgraph of a node with this mixin. What
> constitutes a significant modification will depend on the semantics of
> the various
> parts of a node's subgraph and is implementation-dependent."
> 
> Since the "protected" attributes are variant, we can implement them as we wish.
> i would like to have a "good" jcr:lastModified behavior that is
> directly provided by the repository.
> OTOH when dealing with files (nt:file) uploaded from a filesystem, it
> probably makes sense to transport the last-modified of the original
> file.
> 
> we need to define:
> 1) does jackrabbit support automatic jcr:lastModified computation ?
> 2) if yes, do we make it protected ?
> 3) what operations on which scope affect which jcr:lastModified properties
> 4) does changing the jcr:lastModified property trigger an observation event?
> 
> at a first glance, i would say:
> 1) yes, please support it

+1 (and apply to jcr:lastModifiedBy property, too)

> 2) no, keep it writable

+2 (and apply to jcr:lastModifiedBy property, too)

1) and 2) combined would give us the best result probably: By default
(and when the mixin is first applied to a node) the property is set to
the current time. But this may then be overwritten by an uploaded file's
effective last modified timestamp.

Another use case would be a JSP Compiler writing class files into the
repository (as we do in Sling). Such a compiler could set the
jcr:lastModified and jcr:lastModifiedBy properties to the values of the
respective properties of the JSP source file.

> 3) all changes (except versioning and import operations) in an
> mix:lastModified aggregate affect it's last modified property. the
> aggregate is defined as sub-tree below a mix:lastModified node,
> without all other mix:lastModified sub-trees.

+1, makes absolute sense

> 4) don't know - probably not

I think it should because:
  -- the jcr:lastModified[By] property is modified automatically
     if other content is changed. Hence it is part of a bigger
     content update and we would expect such an event
  -- if the jcr:lastModified[By] property is explicitly modified,
     it is a modification like any other modification and must
     have an event.

Regards
Felix
> 
> WDYT ?
> regards, toby
>