[jira] [Commented] (OAK-784) HBase microkernel prototype contribution
[ https://issues.apache.org/jira/browse/OAK-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638879#comment-13638879 ] Michael Dürig commented on OAK-784: --- Thanks Damien, great stuff! I think we should commit this to the Jackrabbit sandbox to make it more visible and easier to try out. WDYT? HBase microkernel prototype contribution Key: OAK-784 URL: https://issues.apache.org/jira/browse/OAK-784 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Damien Obrist Priority: Minor Attachments: oak-mk-hbase.zip In the course of my internship at Adobe I have developed an HBase microkernel prototype for Oak, which - after discussion with some of the Oak folks - I would like to contribute to the project. I'll attach the zipped code to this issue, let me know if there's anything that I should do. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-781) Clarify / fix effects of MISSING_NODE as base state of NodeBuilder
[
https://issues.apache.org/jira/browse/OAK-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638901#comment-13638901
]
Michael Dürig commented on OAK-781:
---
bq. It would seem like a better idea to use the exists() status of the
underlying base NodeState
Right, hat should do.
bq. it occurred to me that renaming getChild and addChild...
Agreed. IMO we should even rename the rename {{addChild(String)}} to
{{setNode(String)}} since it has the semantics of {{setNode(foo,
EMPTY_NODE)}}.
bq. Thinking more generally about the MemoryNodeBuilder...
I think the current design makes sense in general and fulfils the first two
bullet points above. What we need to do IMO is
* update the Javadoc the current design,
* don't access {{MutableNodeState}}'s state directly but use accessors whose
name capture the intended semantics,
* differentiate between {{read() / write()}} and a new set of methods (e.g.
{{base() / head()}}. The former pair would update a builder's state for read /
write access while the latter pair would update a builder's base / head state.
Currently this functionality is intertwined in {{read() / write()}}.
Regarding moving the purge logic below the {{NodeBuilder}} there is OAK-659. As
stated in the cited [discussion |
http://markmail.org/message/lbc3rx2p3sssvqj5], the transient move operations
are troublesome. Maybe we could use an approach as suggested in OAK-783 and
annotate moved nodes with a reference to their source in their original
revision? I think this should give us enough information to come up with
workable solutions later on.
Clarify / fix effects of MISSING_NODE as base state of NodeBuilder
--
Key: OAK-781
URL: https://issues.apache.org/jira/browse/OAK-781
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Attachments:
0001-OAK-781-Clarify-fix-effects-of-MISSING_NODE-as-base-.patch, OAK-781.patch
Having a {{MISSING_NODE}} respectively a node state that returns false for
its {{exists}} method as a base state of a node builder results in undefined
behaviour. We need to clarify how to handle such cases for resolving OAK-766.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-790) ResultRow#getSize() always returns -1
angela created OAK-790: -- Summary: ResultRow#getSize() always returns -1 Key: OAK-790 URL: https://issues.apache.org/jira/browse/OAK-790 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela just had a failing test due to the fact that my code was trying to find out if the query produce any result before starting to look over the result entries. that didn't work since ResultRow#getSize() always returned -1. if fixed my problem by just getting rid of ResultRow#getSize(). i would suggest to either - implement getSize() for 'nothing-found' and/or a few results found - drop the method from the OAK interface altogether if we are never going to implement - add #isEmpty for those cases were someone just wanted to know if a query found something without the need of knowing the exact number. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-775) Implement backward compatible observation
[
https://issues.apache.org/jira/browse/OAK-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638907#comment-13638907
]
Jukka Zitting commented on OAK-775:
---
An alternative, hybrid solution that would partially solve the problem without
requiring us to persist events would be to only support user data for
non-externel events.
AFAICT, most of the existing observation listeners that require the userId and
other user data to be present already guard event processing with a
{{!event.isExternal()}} check, so this approach would allow us to avoid most of
the mentioned backwards compatibility issues.
To make this happen we'd need to hook the observation dispatcher back into
{{NodeStoreBranch.merge()}} and have it dispatch events between the base and
the head state of the branch together with information about the current user.
Any other changes before and after such local commits would be reported without
associated user information.
Implement backward compatible observation
-
Key: OAK-775
URL: https://issues.apache.org/jira/browse/OAK-775
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, jcr
Reporter: Michael Dürig
Assignee: Michael Dürig
Attachments: OAK-775-isExternal.patch, OAK-775.patch
As [discussed | http://markmail.org/message/6bqycmx6vbq7m25c] we might want
look into implementing an alternative approach to observation, which trades
some scalability for improved backward compatibility.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-757) Merge DefaultTypeEditor into the TypeEditor
[ https://issues.apache.org/jira/browse/OAK-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-757. - Resolution: Fixed Fix Version/s: 0.7 in with rev 1470862. I did not change/refactor anything, I only merged the bits together. Merge DefaultTypeEditor into the TypeEditor --- Key: OAK-757 URL: https://issues.apache.org/jira/browse/OAK-757 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Alex Parvulescu Assignee: Alex Parvulescu Fix For: 0.7 Attachments: OAK-757.patch As proposed on OAK-673, the functionality provided by the DefaultTypeEditor can be very well merged into what the TypeEditor is doing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-790) ResultRow#getSize() always returns -1
[ https://issues.apache.org/jira/browse/OAK-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638916#comment-13638916 ] Thomas Mueller commented on OAK-790: What about renaming getSize() to getSizeOrUnknown()? ResultRow.getSize() does return a value = 0 in some cases, for example if the query contains order by. But I understand for your query it always returns -1. drop the method from the OAK interface altogether if we are never going to implement That's not an option, as it is needed and used in oak-jcr. add isEmpty That's an option, but I wonder if it is really useful right now. We could implement it as ResultRow.getRows().iterator().hasNext(). But in your case, as far as I understand, you are interested in the rows as well. I suggest we wait implementing isEmpty currently, until we have a case where somebody is only interested in the isEmpty information but not in the rows (unless that's already the case). ResultRow#getSize() always returns -1 - Key: OAK-790 URL: https://issues.apache.org/jira/browse/OAK-790 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela just had a failing test due to the fact that my code was trying to find out if the query produce any result before starting to look over the result entries. that didn't work since ResultRow#getSize() always returned -1. if fixed my problem by just getting rid of ResultRow#getSize(). i would suggest to either - implement getSize() for 'nothing-found' and/or a few results found - drop the method from the OAK interface altogether if we are never going to implement - add #isEmpty for those cases were someone just wanted to know if a query found something without the need of knowing the exact number. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-781) Clarify / fix effects of MISSING_NODE as base state of NodeBuilder
[
https://issues.apache.org/jira/browse/OAK-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-781:
--
Attachment: memorynodebuilder-1.png
As additional {{MemoryNodeBuilder}} documentation I attached a class diagram
that outlines key parts of the design.
bq. IMO we should even rename the rename addChild(String) to setNode(String)
since it has the semantics of setNode(foo, EMPTY_NODE).
Agreed; or just drop the separate method signature in favor of {{setNode(foo,
EMPTY_NODE)}}.
bq. What we need to do IMO is
update the Javadoc the current design
My take here was to start form a bit higher level before going directly to
Javadoc, as earlier on I spent some hours of effort on MemoryNodeBuilder
javadocs that nowadays are already out of date.
bq. don't access MutableNodeState's state directly but use accessors whose name
capture the intended semantics
+1 We should also move MutableNodeState to a separate, package-private class
instead of keeping it internal to MemoryNodeBuilder. It originally started as
an internal class to keep it tightly hidden as a MemoryNodeBuilder
implementation detail, but it's getting complex enough to warrant it's own
source file and separate unit tests.
bq. purge logic
OK, let's follow up in OAK-659.
Clarify / fix effects of MISSING_NODE as base state of NodeBuilder
--
Key: OAK-781
URL: https://issues.apache.org/jira/browse/OAK-781
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Attachments:
0001-OAK-781-Clarify-fix-effects-of-MISSING_NODE-as-base-.patch,
memorynodebuilder-1.png, OAK-781.patch
Having a {{MISSING_NODE}} respectively a node state that returns false for
its {{exists}} method as a base state of a node builder results in undefined
behaviour. We need to clarify how to handle such cases for resolving OAK-766.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-673) Unified hook processing
[ https://issues.apache.org/jira/browse/OAK-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638996#comment-13638996 ] Alex Parvulescu commented on OAK-673: - for the record, merging all the editor together would mean that the property indexer would miss the uuid property added by the version editor, causing the VersionHistoryTest#testGetVersionHistoryNodeByUUID test to fail. I'm now wondering if there's a way to go around this problem. Unified hook processing --- Key: OAK-673 URL: https://issues.apache.org/jira/browse/OAK-673 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: OAK-673-VersionHook.patch As [discussed|http://markmail.org/message/xqw3yg3z5rnsiwz3] on oak-dev@, it would be good reduce the number of separate content diffs that various hooks do during each commit. To do this without having to merge unrelated functionality into one big hook class we should come up with a new hook generalization, like the one I [proposed|http://markmail.org/message/bydje7rf3si67fc3], that allows multiple independent components to process the results of a single content diff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-758) Implement AC-editing by principal (Jackrabbit API)
[ https://issues.apache.org/jira/browse/OAK-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13639055#comment-13639055 ] angela commented on OAK-758: fixed the initial draft and added some tests at revision 1470950. Implement AC-editing by principal (Jackrabbit API) -- Key: OAK-758 URL: https://issues.apache.org/jira/browse/OAK-758 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela see AccessControlManagerImpl line 216 and 262. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-758) Implement AC-editing by principal (Jackrabbit API)
[ https://issues.apache.org/jira/browse/OAK-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-758. Resolution: Fixed Implement AC-editing by principal (Jackrabbit API) -- Key: OAK-758 URL: https://issues.apache.org/jira/browse/OAK-758 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela see AccessControlManagerImpl line 216 and 262. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-673) Unified hook processing
[ https://issues.apache.org/jira/browse/OAK-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13639081#comment-13639081 ] Alex Parvulescu commented on OAK-673: - hmm, it is indeed related to the order of editors, but I don't think it's the same issue. So assuming we've merged all editors in, what happens is that the VersionEditor creates a version node (with a uuid property) that is missed by the indexer because there's no #proeprtyChanged even fired, so the property index is not updated. Next when the test tried to load the node by id, it fails because the index does not contain that entry. Separating the version from the index in 2 different commit hooks works because the indexer will pickup the changes that the version editor did. Unified hook processing --- Key: OAK-673 URL: https://issues.apache.org/jira/browse/OAK-673 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: OAK-673-VersionHook.patch As [discussed|http://markmail.org/message/xqw3yg3z5rnsiwz3] on oak-dev@, it would be good reduce the number of separate content diffs that various hooks do during each commit. To do this without having to merge unrelated functionality into one big hook class we should come up with a new hook generalization, like the one I [proposed|http://markmail.org/message/bydje7rf3si67fc3], that allows multiple independent components to process the results of a single content diff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-673) Unified hook processing
[ https://issues.apache.org/jira/browse/OAK-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13639114#comment-13639114 ] Alex Parvulescu commented on OAK-673: - I think the same will happen if we refactored the ConflictHook into an Editor. The ConflictHook would add some conflict markers which would be probably ignored by the ConflictValidator if it all happened in one single commit. Unified hook processing --- Key: OAK-673 URL: https://issues.apache.org/jira/browse/OAK-673 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: OAK-673-VersionHook.patch As [discussed|http://markmail.org/message/xqw3yg3z5rnsiwz3] on oak-dev@, it would be good reduce the number of separate content diffs that various hooks do during each commit. To do this without having to merge unrelated functionality into one big hook class we should come up with a new hook generalization, like the one I [proposed|http://markmail.org/message/bydje7rf3si67fc3], that allows multiple independent components to process the results of a single content diff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-325) QueryEngine can't handle node type hierarchies
[ https://issues.apache.org/jira/browse/OAK-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13639277#comment-13639277 ] Jukka Zitting commented on OAK-325: --- In http://svn.apache.org/r1471042 I followed up with a pretty comprehensive overhaul that extends proper node type handling to the remaining bits of the query engine. QueryEngine can't handle node type hierarchies -- Key: OAK-325 URL: https://issues.apache.org/jira/browse/OAK-325 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: Alex Parvulescu Fix For: 0.6 Test class: MixinTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
