On 27.11.12 12:39, Thomas Mueller wrote:
Currently we work around this problem by mapping each
>higher-level copy and move operation to separate branch commits that
>contain just that operation, which isn't too ideal.
Could you tell me what problems you see with this workaround? As far as I
kn
Hi Jukka,
Thanks for sharing this. In a nutshell, what you are proposing to do is
* to keep no more than one move/copy operation pending and purge changes
to the Microkernel as soon as another such operation arrives,
* in the generalised version, to only keep "unconflicting" move/copy
opera
Hi,
On Tue, Nov 27, 2012 at 5:11 PM, Angela Schreiber wrote:
> IMO that will not work for the case manfred is referring
> to as it is operating on the oak-api and not on jcr api.
After thinking about this for some while, I actually wonder whether it
would be better for the authentication code to
hi michael
thanks for the summary.
i don't agree with your statement that it was "unnecessary and even
wrong" to delegate handling of the special elements current (".") and
parent ("..") in the OAK API and fail to see any benefit of allowing
child nodes with such names on that level.
so, it
hi michael
rootNode.getOrAddTree("a/b/../../c/d/../../e/f", "");
adds the three sub trees /a/b, /c/d and /e/f. Is this really the
intended behaviour?
yes... see als JcrUtil in jackrabbit-commons.
kind regards
angela
hi tom
IMO that will not work for the case manfred is referring
to as it is operating on the oak-api and not on jcr api.
so -1 for that one.
kind regards
angela
On 11/27/12 3:22 PM, Thomas Mueller wrote:
Hi,
Currently it is planned to use the commit hook feature to update the
index. Is the co
Hi,
On Tue, Nov 27, 2012 at 4:22 PM, Thomas Mueller wrote:
> If it can't be easily supported, maybe a simple per-session map (uuid ->
> path) could be used for temporary nodes, within oak-jcr?
+1, sounds like a plan.
BR,
Jukka Zitting
Hi,
On Tue, Nov 27, 2012 at 12:56 PM, Jukka Zitting wrote:
> I did some work along these lines already earlier with the
> CopyAndMoveAwareJsopDiff class you can find inside KernelRootBuilder,
> but couldn't make it work properly. Based on discussions with Michael
> last week I think we should be
On 27.11.12 14:22, Thomas Mueller wrote:
Hi,
Currently it is planned to use the commit hook feature to update the
index. Is the commit hook called before saving?
No, it wouldn't be a commit hook then. The question is, whether the
indexing code depends on being called on commit only. Otherwi
Hi,
Currently it is planned to use the commit hook feature to update the
index. Is the commit hook called before saving?
If it can't be easily supported, maybe a simple per-session map (uuid ->
path) could be used for temporary nodes, within oak-jcr?
Regards,
Thomas
On 11/27/12 3:08 PM, "Mich
Hi,
I think we should be able to address this by adding the capability to
update the index in transient space already instead of waiting for the
commit as Jukka mentioned [1].
Alex, Tom, do you think something along these lines would be feasible?
Michael
[1]
https://issues.apache.org/jira
Hi,
to track this more easily I committed the pseudo code to svn:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/doc/jsop-diff.md?view=markup
A small correction to my initial post is here:
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/doc/jsop-diff.md?r1=1414189&r2=1414190&pathrev=141
ok, I've created OAK-478
if you find a fix, please also commit the path (which will remove the node
types :)
thanks,
alex
https://issues.apache.org/jira/browse/OAK-478
On Tue, Nov 27, 2012 at 11:50 AM, Jukka Zitting wrote:
> Hi,
>
> On Tue, Nov 27, 2012 at 12:46 PM, Michael Dürig
> wrote:
>
Hi,
As mentioned in my previous message, here is a draft of an algorithm
which should be capable of creating a change log from two trees, such
that when the change log is applied to the source tree it will transform
it to the destination tree. The algorithm is capable of coping with copy
and
Hi,
>1) For each tree node we keep track of its original location.
> However, I think recording the path is not sufficient. We need to record
>the parent node.
I guess you don't mean remembering the original path of the parent?
keeping track of the original location of the parent (let's say "/te
Hi,
On 27.11.12 10:56, Jukka Zitting wrote:
Hi,
As discussed at length earlier, in oak-core we only keep track of tree
states instead of change logs, i.e. the sequences of changes that lead
from one state to another. This works pretty well in general and
avoids a lot of extra complexity, but p
Hi,
As discussed at length earlier, in oak-core we only keep track of tree
states instead of change logs, i.e. the sequences of changes that lead
from one state to another. This works pretty well in general and
avoids a lot of extra complexity, but poses the question of how to
best produce the JSO
Hi,
On Tue, Nov 27, 2012 at 12:46 PM, Michael Dürig wrote:
> On 23.11.12 15:17, alexparvule...@apache.org wrote:
>> - added node types to the index nodes, to prevent a NPE in the node type
>> validation code
>
> Thanks for fixing this. However, I think we should also fix the NPE. A
> missing no
On 23.11.12 15:17, alexparvule...@apache.org wrote:
Author: alexparvulescu
Date: Fri Nov 23 15:17:00 2012
New Revision: 1412910
URL: http://svn.apache.org/viewvc?rev=1412910&view=rev
Log:
OAK-154 Full text search index
- added node types to the index nodes, to prevent a NPE in the node type
19 matches
Mail list logo
