jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Drop PropertyState?
Date Fri, 16 May 2008 08:01:56 GMT
hi jukka,
generally i think this might be a good idea, at least for jsr283,
where item.save() item.refresh() is dropped. it's hard to guess all
implications, since the propertystate concept is widely used
throughout the core. for example the changelog records all
modifications of property states, this need to be handled differently,
and becomes quite larger since it needs to track the states of all
properties of the node.
further is the entire observation stuff based on the changelog of
modified states, so this needs to be rewritten, too.  further do we
need to adjust all persistence managers that can store individual
property states today (of course this can be an simple wrapper). and
think of the complexity in the item state listeners and cache

if we gonna change this, i suggest to also introduce an adjusted
persistencemanager interface (or lets call it then BundleStore).

i think this will be a huge rewrite which will imply months of
instability and testing, and i frankly don't know if it's worth it.
additionally, wouldn't it compromise the NG data model?

regards, toby

On 5/16/08, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>  An idea I had when waking up this morning: How about if we dropped the
>  PropertyState class and related stuff like PropertyId and the
>  per-property access methods in persistence managers and elsewhere?
>  The rationale? See below:
>  1) Bundles are already the recommended way for storing content on the
>  persistence layer, and we need extra machinery for splitting and
>  recomposing bundles from separate node and property states.
>  2) As discussed in JCR-1552, the need for fine-grained tracking of
>  property states is debatable and perhaps even harmful from the client
>  perspective.
>  3) This change would notably simplify core internals, as we could
>  collapse the item, property, and node state classes into a single
>  bundle class and get rid of many code branches on whether an item
>  state is for a property or a node.
>  The expense would be increased size and complexity in the "bundle
>  state" class, but I think it might well be worth it.
>  WDYT?
>  BR,
>  Jukka Zitting

View raw message