jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: behavior of jcr:lastModified in jackrabbit 2.0
Date Thu, 18 Jun 2009 07:07:18 GMT

2009/6/17 Tobias Bocanegra <tobias.bocanegra@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


> 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.


View raw message