date:20131105

[jira] [Reopened] (OAK-210) granularity of persisted data

2013-11-05 Thread Stefan Guggisberg (JIRA)


 [ 
https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg reopened OAK-210:
---


i don't agree with the resolution 'Incomplete'. 

the description is IMO pretty clear.

 granularity of persisted data
 -

 Key: OAK-210
 URL: https://issues.apache.org/jira/browse/OAK-210
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg

 the current persistence granularity is _single nodes_ (a node consists of 
 properties and child node information). 
 instead of storing/retrieving single nodes it would IMO make sense to store 
 subtree aggregates of specific nodes. the choice of granularity could be 
 based on simple filter criteria (e.g. property value).
 dynamic persistence granularity would help reducing the number of records and 
 r/w operations on the underlying store, thus improving performance.  



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1133) Observation listener PLUS

2013-11-05 Thread JIRA


[ 
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813767#comment-13813767
 ] 

Michael Dürig commented on OAK-1133:


I think once the suggested refactorings from OAK-1143 are done, it should be 
quite easy to extend the current observation mechanism to cater of most/all of 
the requirements listed here and also include things from the patch on OAK-1120 
as well as including the {{ExcludeExternal}} semantics from OAK-1121

 Observation listener PLUS
 -

 Key: OAK-1133
 URL: https://issues.apache.org/jira/browse/OAK-1133
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: commons, jcr
Reporter: Alexander Klimetschek
  Labels: performance

 Oak should provide an *extended and efficient JCR observation listener* 
 mechanism to support common use cases not handled well by the restricted 
 options of the JCR observation (only base path, node types and raw events). 
 Those cases require listeners to register much more broadly and then filter 
 out their specific cases themselves, thus putting too many events into the 
 observation system and creating a huge overhead due to asynchronous access to 
 the modified JCR data to do the filtering. This easily is a big performance 
 bottleneck with many writes and thus many events.
 Previous discussions [on the 
 list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120.
 The goals should be:
 * performance: handle filtering as early as possible, during the commit, 
 where access to the modified data is already present
 * provide robust implementation for typical filtering cases
 * provide an asynchronous listener mechanism as in JCR
 * minimize effect on the lower levels on Oak (a visible addition in 
 oak-commons or oak-jcr should be enough)
 * for delete events, allow filtering on the to-be-deleted data (currently not 
 possible in jcr listeners that run after the fact)
 * ignore external cluster events by default; have an extra option if you 
 really want to register for external events
 * if possible: design as an extension of the jcr observation to simplify 
 migration for existing code
 * if possible: provide an intelligent listener that can work with pure JCR 
 (aka Jackrabbit 2) as well, by falling back to in-listener-filtering
 * maybe: synchronous option using the same simple interface (instead of raw 
 Oak plugins itself); however, not sure if there is a benefit if they can only 
 read data and not change or block the session commit
 Typical filtering cases:
 - paths with globbing support (for example /content/foo/*/something)
 - check for property values (equal, not equal, contains etc.), most 
 importantly
 sling:resourceType in Sling apps
 - allow to check properties on child nodes as well, typically jcr:content
 - check for any parent/ancestor as well (e.g. change deep inside a node type 
 = foo structure should be triggered, even if the node with the type wasn't 
 modified; very important to support efficiently)
 - node types (already in jcr observation)
 - created/modified/deleted events, separate from move/copy
 - and more... a custom filter should be possible to pass through (with 
 similar access as the {{Observer}})



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-11-05 Thread Stefan Guggisberg (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813766#comment-13813766
 ] 

Stefan Guggisberg commented on OAK-1126:


bq. AFAICT the only change to the JSOP format would be to adjust the addNode 
syntax to use the :children mechanism for child nodes. 

that's what i meant by json_diff format changes. it's IMO a drastic change 
since it makes importing arbitrary JSON impossible (or at least very awkward). 

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 
 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-11-05 Thread Thomas Mueller (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813781#comment-13813781
 ] 

Thomas Mueller commented on OAK-1126:
-

 it makes importing arbitrary JSON impossible

Hm, we already have quite a few limitations, for example array may only contain 
values of the same type, (and not objects).

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 
 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-11-05 Thread JIRA


[ 
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813785#comment-13813785
 ] 

Michael Dürig commented on OAK-1126:


bq. since it makes importing arbitrary JSON impossible (or at least very 
awkward). 

This was never a use case. From the beginning on oak-core was deemed to be the 
only client to the MicroKernel ever. 

 Same node and property name support
 ---

 Key: OAK-1126
 URL: https://issues.apache.org/jira/browse/OAK-1126
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core, doc, jcr
Reporter: Tobias Bocanegra
 Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch, 
 0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch


 The initial MK abstraction mandated that the nodes and properties share the 
 same namespace 
 (http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This 
 is a regression from Jackrabbit 2.x, which supports same name nodes and 
 properties (SNNP).
 OTOH, the NodeStores can easily support SNNP and with proper escaping, the 
 MKs can also support it.
 We should try to keep the support for SNNP in order to keep backward 
 compatibility for existing content, and also keep the support for importing 
 XML documents with same attribute and element names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1131) Provide a way to inject Observer instances into NodeStore implementations

2013-11-05 Thread Marcel Reutegger (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813790#comment-13813790
 ] 

Marcel Reutegger commented on OAK-1131:
---

Done in revision: http://svn.apache.org/r1538908

 Provide a way to inject Observer instances into NodeStore implementations 
 --

 Key: OAK-1131
 URL: https://issues.apache.org/jira/browse/OAK-1131
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Michael Dürig

 Currently {{KernelNodeStore}} has a public {{setObserver()}} method, 
 {{SegmentNodeStore}} has its {{Observer}} hard coded to the empty observer 
 and no way to set it and {{MongoNodeStore}} has no {{Observer}} at all. 
 To make the observer mechanism useful for clients we should come up with a 
 way to inject {{Observer}} instances into a {{NodeStore}}.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1126) Same node and property name support

2013-11-05 Thread Stefan Guggisberg (JIRA)

[
https://issues.apache.org/jira/browse/OAK-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813798#comment-13813798
]

Stefan Guggisberg commented on OAK-1126:

bq. This was never a use case. From the beginning on oak-core was deemed to be
the only client to the MicroKernel ever.

i beg to differ. the MicroKernel API was designed to be portable from scratch.
therefore it's obvious that it's possible to implement and use it in different
languages/stacks (e.g. c, nodejs, etc).

Same node and property name support
---

Key: OAK-1126
URL: https://issues.apache.org/jira/browse/OAK-1126
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, doc, jcr
Reporter: Tobias Bocanegra
Attachments: 0001-OAK-1126-Same-node-and-property-name-support.patch,
0002-OAK-1126-Same-node-and-property-name-support.patch, OAK-1126.patch

The initial MK abstraction mandated that the nodes and properties share the
same namespace
(http://wiki.apache.org/jackrabbit/RepositoryMicroKernel#Data%20Model). This
is a regression from Jackrabbit 2.x, which supports same name nodes and
properties (SNNP).
OTOH, the NodeStores can easily support SNNP and with proper escaping, the
MKs can also support it.
We should try to keep the support for SNNP in order to keep backward
compatibility for existing content, and also keep the support for importing
XML documents with same attribute and element names.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (OAK-1133) Observation listener PLUS

2013-11-05 Thread Thomas Mueller (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813804#comment-13813804
 ] 

Thomas Mueller commented on OAK-1133:
-

  listener registrations would include whether they care about local or 
 external events
 very dedicated extra step in the registration API to do so

Yes, that makes sense. It should be relatively hard to register listeners for 
external events.

 This is not convenience, this is reducing unnecessary work.

It's probably both convenience and reducing work. Convenience is good, if it 
results in less and/or clearer code :-)


 Observation listener PLUS
 -

 Key: OAK-1133
 URL: https://issues.apache.org/jira/browse/OAK-1133
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: commons, jcr
Reporter: Alexander Klimetschek
  Labels: performance

 Oak should provide an *extended and efficient JCR observation listener* 
 mechanism to support common use cases not handled well by the restricted 
 options of the JCR observation (only base path, node types and raw events). 
 Those cases require listeners to register much more broadly and then filter 
 out their specific cases themselves, thus putting too many events into the 
 observation system and creating a huge overhead due to asynchronous access to 
 the modified JCR data to do the filtering. This easily is a big performance 
 bottleneck with many writes and thus many events.
 Previous discussions [on the 
 list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120.
 The goals should be:
 * performance: handle filtering as early as possible, during the commit, 
 where access to the modified data is already present
 * provide robust implementation for typical filtering cases
 * provide an asynchronous listener mechanism as in JCR
 * minimize effect on the lower levels on Oak (a visible addition in 
 oak-commons or oak-jcr should be enough)
 * for delete events, allow filtering on the to-be-deleted data (currently not 
 possible in jcr listeners that run after the fact)
 * ignore external cluster events by default; have an extra option if you 
 really want to register for external events
 * if possible: design as an extension of the jcr observation to simplify 
 migration for existing code
 * if possible: provide an intelligent listener that can work with pure JCR 
 (aka Jackrabbit 2) as well, by falling back to in-listener-filtering
 * maybe: synchronous option using the same simple interface (instead of raw 
 Oak plugins itself); however, not sure if there is a benefit if they can only 
 read data and not change or block the session commit
 Typical filtering cases:
 - paths with globbing support (for example /content/foo/*/something)
 - check for property values (equal, not equal, contains etc.), most 
 importantly
 sling:resourceType in Sling apps
 - allow to check properties on child nodes as well, typically jcr:content
 - check for any parent/ancestor as well (e.g. change deep inside a node type 
 = foo structure should be triggered, even if the node with the type wasn't 
 modified; very important to support efficiently)
 - node types (already in jcr observation)
 - created/modified/deleted events, separate from move/copy
 - and more... a custom filter should be possible to pass through (with 
 similar access as the {{Observer}})



--
This message was sent by Atlassian JIRA
(v6.1#6144)

44 matches

Mail list logo