jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: behavior of jcr:lastModified in jackrabbit 2.0
Date Thu, 18 Jun 2009 06:30:53 GMT

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.

> WDYT ?
> regards, toby

View raw message