jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Getting Version History after the node is deleted
Date Wed, 11 Apr 2007 07:43:31 GMT
On 4/11/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 4/10/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
> > On a more theoretical level: isn't this a limitation of the spec? By
> > the time you remove the event the path information attached to the
> > event is quite useless, so the mechanism should try to publish more
> > usefull information.
>
> I think the remove events are most useful for ensuring coherency for
> applications that cache parts of the repository content (a good
> example would be an external search engine). Cache eviction only needs
> the item path as the key of the cached entry.
>

... if you used that as a key and not the UUID or a "natural key"
based on the node properties.

> What use cases do you think would benefit from more information in the
> event records?
>

I don't have real scenarios right now, but I am seeing Sudhan example,
and I guess we can imagine quite a few (take for example workflow
notifications). Probably the best alternative would be to publish
through the event a shallow copy/dettached copy of the deleted node,
so that you still have most of the information available. I know that
this can be solved in your app with custom made code around special
removal ops, but if you look at this as a cross cutting concern, then
having more information published through event would lead to a lot of
possibilities.

bests,

./alex
--
.w( the_mindstorm )p.
_____________________________________
  Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
  Information Queue ~ www.InfoQ.com



> BR,
>
> Jukka Zitting
>
Mime
View raw message