Drop PropertyState?

[Jukka Zitting]

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

[Tobias Bocanegra]

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

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

[Jukka Zitting]

Hi,

On Fri, May 16, 2008 at 11:01 AM, Tobias Bocanegra
<tobias.bocanegra@...> wrote:
> 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?

I think this would fit fairly well with NG (I'm not sure if I've noted
it anywhere, but I've always thought of NGP as being bundle-based),
and we could use this as an iterative step towards it.

(Another potential iterative step could be for example storing entire
bundles in the journal, and implementing a persistence manager that
gets its content from the journal instead of a separate storage.)

I'm not sure whether this kind of a refactoring would be worth the
effort, or if we should just look at doing a rewrite from the ground
at some point in the future. Instinctively I'd prefer an iterative
approach.

BR,

Jukka Zitting

[Tobias Bocanegra]

> Hi,
>
>
>  On Fri, May 16, 2008 at 11:01 AM, Tobias Bocanegra
>  <tobias.bocanegra@...> wrote:
>  > 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?
>
>
> I think this would fit fairly well with NG (I'm not sure if I've noted
>  it anywhere, but I've always thought of NGP as being bundle-based),
>  and we could use this as an iterative step towards it.

oh really? i though it's better to have very fine difference sets. for
example adding a new property to a "big" node, would only result in
'add property' as a difference, but when you have bundles, you would
have to store the entire bundle as diff.

>  (Another potential iterative step could be for example storing entire
>  bundles in the journal, and implementing a persistence manager that
>  gets its content from the journal instead of a separate storage.)
..and the changelog. so that the modifications of a transaction are
direclty store the the journaled persistence manager and the commit
would result it marking the changes as active.

>  I'm not sure whether this kind of a refactoring would be worth the
>  effort, or if we should just look at doing a rewrite from the ground
>  at some point in the future. Instinctively I'd prefer an iterative
>  approach.
me, too.

--
regards, toby

[Jukka Zitting]

Hi,

On Fri, May 16, 2008 at 2:59 PM, Tobias Bocanegra
<tobias.bocanegra@...> wrote:
>> I think this would fit fairly well with NG (I'm not sure if I've noted
>>  it anywhere, but I've always thought of NGP as being bundle-based),
>>  and we could use this as an iterative step towards it.
> oh really? i though it's better to have very fine difference sets. for
> example adding a new property to a "big" node, would only result in
> 'add property' as a difference, but when you have bundles, you would
> have to store the entire bundle as diff.

You could do a "diff bundle", ie. one that references the previous
revision and includes only the changes. The parent node of a modified
property needs to be updated in the new revision in any case if we go
with a Subversion-like structure where the entire path from a
modification to the root node needs to be included in a revision.

>>  (Another potential iterative step could be for example storing entire
>>  bundles in the journal, and implementing a persistence manager that
>>  gets its content from the journal instead of a separate storage.)
> ..and the changelog. so that the modifications of a transaction are
> direclty store the the journaled persistence manager and the commit
> would result it marking the changes as active.

Good point! Handled correctly, that would even cover some of the
memory issues related to large transient or directly persisted
operations.

BR,

Jukka Zitting

[Tobias Bocanegra]

On 5/16/08, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
>  On Fri, May 16, 2008 at 2:59 PM, Tobias Bocanegra
>
> <tobias.bocanegra@...> wrote:
>
> >> I think this would fit fairly well with NG (I'm not sure if I've noted
>  >>  it anywhere, but I've always thought of NGP as being bundle-based),
>  >>  and we could use this as an iterative step towards it.
>  > oh really? i though it's better to have very fine difference sets. for
>  > example adding a new property to a "big" node, would only result in
>  > 'add property' as a difference, but when you have bundles, you would
>  > have to store the entire bundle as diff.
>
>
> You could do a "diff bundle", ie. one that references the previous
>  revision and includes only the changes. The parent node of a modified
>  property needs to be updated in the new revision in any case if we go
>  with a Subversion-like structure where the entire path from a
>  modification to the root node needs to be included in a revision.
>
>
>  >>  (Another potential iterative step could be for example storing entire
>  >>  bundles in the journal, and implementing a persistence manager that
>  >>  gets its content from the journal instead of a separate storage.)
>  > ..and the changelog. so that the modifications of a transaction are
>  > direclty store the the journaled persistence manager and the commit
>  > would result it marking the changes as active.
>
>
> Good point! Handled correctly, that would even cover some of the
>  memory issues related to large transient or directly persisted
>  operations.

i think this might by a change (introduce tx aware pms) that we could
introduce independently from the 'drop property state' issue.

[Alexander Klimetschek]

On Fri, May 16, 2008 at 2:31 PM, Tobias Bocanegra <tobias.bocanegra@...>
wrote:

> >  >>  (Another potential iterative step could be for example storing
> entire
> >  >>  bundles in the journal, and implementing a persistence manager that
> >  >>  gets its content from the journal instead of a separate storage.)
> >  > ..and the changelog. so that the modifications of a transaction are
> >  > direclty store the the journaled persistence manager and the commit
> >  > would result it marking the changes as active.
> >
> >
> > Good point! Handled correctly, that would even cover some of the
> >  memory issues related to large transient or directly persisted
> >  operations.
> i think this might by a change (introduce tx aware pms) that we could
> introduce independently from the 'drop property state' issue.
>

In the light of an improved PM interface (NGP, journaled PM or whatever
solution will be best), we should not be constraining the PM how it has to
store data by reducing the methods and forcing it to use bundles (node +
properties + property values in one bundle). For example, the lack of
hierarchy information in the current PM interface makes it impossible for a
backend to improve hierarchy-specific reads (eg. getNodeChildren). Forcing
the concept of bundles into the PM would introduce the same problem.

IMHO it is possible to have a larger set of methods than the current PM, but
still implement it in a bundle-style. It's just about the right abstraction.
I started some work about this recently, which might help in identifying a
good interface for a journaled PM, that could even include the transient
space (for non-memory bound clients). I hope to continue it in the coming
weeks to get a basis for discussion.

Just my 2 cents...
Alex