Hi,
It's not clear to me how to support scalable concurrent writes. This is
also a problem with the current MongoMK design, but I in your design I
actually see more problems in this area (concurrent writes to nodes in the
same segment for example). But maybe it's just that I don't understand
this
Hi,
Ah OK. Then the only solution to avoid those indexes is to not support the
feature I guess.
Regards,
Thomas
On 1/24/13 2:27 PM, "Angela Schreiber" wrote:
>hi jukka
>
>it's not for the access control evaluation nor for access
>by path that the query is used... is for the jackrabbit api
>ex
Hi,
Yes, I would also try to avoid using a query to read the ACLs from the
content tree (for multiple reasons: to avoid maintaining indexes, to speed
up access, to simplify caching).
Regards,
Thomas
On 1/24/13 2:22 PM, "Jukka Zitting" wrote:
>Hi,
>
>On Thu, Jan 24, 2013 at 10:11 AM, angela (J
Hi,
Do we have any real-world data about how many conflicts we typically get?
I would rather avoid adding a complex mechanism for something that occurs
very rarely. Also, why do we need to merge conflicts, and not just throw
the exception to the client? What kind of conflicts can be merged, how
co
Hi,
>>Instead of the MicroKernel trying to merge changes, I would prefer if the
>> MicroKernel would fail if a node was changed, moved or deleted after the
>> base revision of a commit. That way, the MicroKernel API would still
>>need
>> a base revision in the commit call (the base revision would
Hi,
>So I guess I need to understand why it
>is important to commit against base revision in CommitCommandNew.
First, I had a really hard time understanding why we need a base revision
in the commit method.
We found a case where the base revision does make a difference, this case
is documented i
Hi,
A possible use case for a bloom filter :-)
Could you tell us more about where in the code it would help?
One thing bloom filters are not so good is when items need to be removed
later on. So if we keep a bloom filter for removed node (speeding up the
case where a node wasn't deleted for sure
Hi,
For migration options see
http://wiki.apache.org/jackrabbit/BackupAndMigration
There is no migration tool specially for Oak yet. It would be great of
course if you could write such a tool and contribute it!
Regards,
Thomas
On 1/8/13 9:44 PM, "Melanie Drake" wrote:
>Since it seems that no
Hi,
>"But the question is how close the journal has to match the original
>commit, specially "move" and "copy" operations.
Yes. There are various degrees of how close the journal is to the commit.
One option is: the commit is preserved 1:1. The other extreme is: moves
are fully converted to add+r
Hi,
>>So, do "move" and "copy" operations need to be preserved, or can they be
>> converted to "add node" / "remove node"?
>
>Now we are getting somewhere: This is exactly the original topic of
>OAK-464. If the Microkernel converts moves to add/remove, implementing
>rebase on top of that results i
Hi,
>>>2) Allow inconsistent journals.
>>
>> I guess we don't want that. But the question is how close the journal
>>has
>> to match the original commit, specially "move" and "copy" operations. If
>> they need to be preserved (do they?), then it's complicated.
>
>There is no use for a journal whic
the best
solution is.
Regards,
Thomas
On 12/18/12 3:25 PM, "Thomas Mueller" wrote:
>Hi,
>
>>1) Make the definition of conflicts sufficiently strong to exclude such
>>cases. That's Tom's proposal from this Thread.
>
>Ah, OK, I thought you meant it could
Hi,
>1) Make the definition of conflicts sufficiently strong to exclude such
>cases. That's Tom's proposal from this Thread.
Ah, OK, I thought you meant it could still be a problem even with my
proposal.
I guess failing on (node-level-) conflicts would be the most simple
solution, as a start. It
Hi,
>OTOH non conflicting changes could still lead to non commuting journal
>entries and thus merging such changes would require journals to be
>adjusted.
Could you give an example?
Regards,
Thomas
Hi,
>In addition it would be nice to annotate conflicts in some way. This is
>quite easy to do and would allow upper layers to resolve conflicts based
>on specific business logic. Currently we do something along these lines
>with the AnnotatingConflictHandler [1] in oak-core.
Sure, that would mak
Hi,
I think it would be better if we clearly define the rules in the
MicroKernel API. There are various edge cases, and having too much freedom
in the MicroKernel API will make oak-core more complicated I guess.
We should also look at what we did in Jackrabbit 2.x and what problems we
ran into. A
Hi,
I'm sorry it looks like I didn't commit this change. Thanks Jukka for
resolving the issue!
Regards,
Thomas
On 12/5/12 2:48 PM, "Jukka Zitting" wrote:
>Hi,
>
>On Wed, Dec 5, 2012 at 12:41 PM, Michael Dürig wrote:
>> Tests in error:
>> sql2Explain(org.apache.jackrabbit.oak.plugins.index.o
Hi,
It looks like it should be a PropertyValue, and not a PropertyStateValue.
I will fix it.
The easiest solution is to return null for now :-) because actually, the
method is currently not used within the query engine. It is planned for
pseudo-properties such as jcr:score (see the documentation)
Hi,
That way me, sorry. I will fix it.
Regards,
Thomas
On 12/4/12 3:53 PM, "build...@apache.org" wrote:
>The Buildbot has detected a new failure on builder oak-trunk while
>building ASF Buildbot.
>Full details are available at:
> http://ci.apache.org/builders/oak-trunk/builds/1147
>
>Buildbot
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,
>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
/browse/OAK-465
>> Project: Jackrabbit Oak
>> Issue Type: Bug
>> Components: query
>>Reporter: Thomas Mueller
>>Assignee: Thomas Mueller
>>
>> The org.apache.jackrabbit.oak.plugins.index.property.Propert
Hi,
For the query engine, I will need a "validate and normalize path" function
that verifies a path is syntactically correct, and simplifies it if
possible, for example:
/a/./b => /a/b
/a/../b => /b
a/.. => .
./a => a
. =>
a/. => a
/.. => invalid
.. => ..
/./. => /
This will not solve the case
Hi,
>before adding this i would rather want to see support for hash maps.
Sounds interesting.. could you give more details please?
Regards,
Thomas
Hi,
>personally i am not aware of real life use cases requiring 'large' mv
>properties.
>
>since the ultimate goal of oak is to provide a JCR implementation and the
>JCR API doesn't provide any methods to manipulate/access single members
>of a mv property i don't think we need to support it under
Hi,
Yes I came to the same conclusion. However I would prefer it Cursor stays
an interface, because it's an API. I could add an abstract class somewhere
else (in the Cursors class): an AbstractCursor class where remove() throws
an exception. Would that be OK as well?
Regards,
Thomas
On 11/14/1
Hi,
Yes, I see. My patch is really just a quick hack (my idea was to avoid
creating many HashMaps), but I'm not sure if it will always work correctly.
Regards,
Thomas
On 11/7/12 4:02 PM, "Michael Dürig" wrote:
>
>
>On 7.11.12 14:54, Thomas Mueller wrote:
>> H
Hi,
>Generational garbage collection should work pretty well for this case.
>If the blob store can keep track of all blobs added since revision X,
>it needs to only go through the diff from that revision the latest
>ones to determine which of those blobs can be removed early.
>
>Since most extra b
Hi,
>the format of references to binaries is documented in the MicroKernel
>java doc,
>see "Retention Policy for Binaries" [0].
Thanks! I didn't know it's already documented.
Regards,
Thomas
tions)?
>>
>> In any case we should definitely avoid to require repo traversal for
>>DSGC. This would operationally limit the repo sizes Oak can support.
>>
>>
>> --
>> Michael Marth | Engineering Manager
>> +41 61 226 55 22 | mma...@adobe.com&
Hi,
>are we actually sure that the existing data store concept is worth the
>trouble?
No, we can't really be sure. There are multiple concepts, one is using a
(cryptographic) hash, an other is to use garbage collection.
As for "garbage collection" versus "delete blob when deleting the
referencin
Hi,
>>If possible, I would try to avoid having to traverse over the whole
>> repository.
>
>Isn't node and revision store GC in the current MicrokernelImpl doing
>exactly that? AFAIR it implements a mark and sweep algorithm which
>periodically traverses the whole repository.
Yes. I guess it's not
Hi,
>If we go down this path for node GC
With "this path" of node GC, do you mean the ability to configure the
lifetime of a revision?
>, doesn't MicroKernel interface have to
>change to account for this? Where would you change this default 10 minutes
>value as far as MicroKernel is concerned?
Hi,
>1- What's considered an "old" node or commit? Technically, anything other
>than the head revision is old but can we remove them right away or do we
>need to retain a number of revisions? If the latter, then how far back do
>we need to retain?
>
>we discussed this a while back, no good solutio
Do other MicroKernel implementations handle this, if so how?
>
>If you have any feedback on any of this, I'd like to hear.
>
>-Mete
>
>On 11/2/12 4:38 PM, "Mete Atamel" wrote:
>
>>Thanks. Yes, I also think it's worthwhile to try implementing MongoDB
Hi,
>Do we have tests somewhere where we
>can compare different BlobStore implementations?
There are some tests in oak-mk-it; MicroKernelIT (testSmallBlob,
testMediumBlob, testLargeBlob). I guess they could be quite easily
converted to test performance.
Regards,
Thomas
Hi,
I would definitely at least *try* to implement a MongoDB BlobStore based
on the AbstractBlobStore. It should be quite simple (one class). Then, it
would be interesting to know which implementation is faster: the GridFS
one or an implementation based on AbstractBlobStore :-) Specially if the
di
Hi,
>I'm not sure what you mean by "used for testing".
I mean used for manual testing. I'm planning to use it for some manual
testing, and I thought others use it as well or plan to use it. I also
want to run some benchmarks to find out if a Lucene index or the property
index is faster.
>It has
Hi,
Yes, it can be removed as soon as the b-tree stuff is migrated - but not
before that :-)
Regards,
Thomas
On 10/25/12 12:00 PM, "Jukka Zitting" wrote:
>402075 I moved the o.a.j.mk packages in oak-core
>to under o.a.j.oak.plugins.index.old.mk. We can remove the code once
>we've migrated all
Hi,
Isn't the property index (o.a.j.oak.plugins.index.old) still used for
testing?
Regards,
Thomas
On 10/24/12 3:05 PM, "Alex Parvulescu" wrote:
>Hi gang,
>
>I'm wondering about 2 issues that are talking about the same refactoring
>task [0] and [1].
>
>There is still a bunch of code there.
>Is
Hi,
As a workaround, you could keep the last few streams open in the Mongo MK
for some time (a cache) together with the current position. That way seek
is not required in most cases, as usually binaries are read as a stream.
However, keeping resources open is problematic (we do that in the
DbData
Hi,
>>Yes, but the problem is if the "repository-administrator" has no way of
>> knowing what indexes are configured.
>
>That's easy to find out:
>
>SELECT * FROM [oak:indexed]
>
>;-)
Your are right. To do this efficiently it would require an index on
[oak:indexed], which would effectively be
Hi,
>It's a bit like in a relational database where you can configure an
>index to use one underlying data structure or another. The more
>indexes you have, the more you need to do when you want to reconfigure
>the indexes.
Yes, but the problem is if the "repository-administrator" has no way of
k
Hi,
It is problematic to fix the configuration if you don't know where to
look, if the configuration can be basically anywhere in the repository.
Let's say there are special Lucene indexes configured at:
/long/path/deep/in/repository
And if you want to switch to another query engine (let's sa
Hi,
No wonder I I couldn't reproduce the problem - I used
mvm -DintegrationTesting clean install
Instead of
mvn -PintegrationTesting clean install
Regards,
Thomas
On 9/20/12 12:21 PM, "Michael Dürig" wrote:
>
>I added the respective tests to the list of known issues at revision
>13879
Hi,
>1) Next to getSize() iterator we also added getTotalSize(). I don't
>like the name because it is actually more something like:
>getTotalSizeWithoutCheckingACLs().
Hm, wouldn't that be a security problem?
Couldn't it be better (from a security perspective) if you can only get
this number if
Hi,
> org.apache.jackrabbit.test.api.query.qom.UpperLowerCaseTest#testLength
> org.apache.jackrabbit.test.api.query.qom.UpperLowerCaseTest#testNodeName
Strange, those tests didn't (and still don't) fail for me. I will
investigate.
Regards,
Thomas
On 9/20/12 12:21 PM, "Michael Dürig" wrote:
Hi,
>+1
>
>From a content modeling perspective, forcing all indexes in a central
>location is very restricting and not modular.
Where the index configuration nodes are stored is normally internal to the
implementation, with the exceptions of export and import.
The index configuration is similar
Hi,
>How do I know it's for sure more than 20
Because the PrefetchIterator will try to prefetch 20 nodes.
>or whatever my page size happens to be?
If you have a higher page size then you need getSize(max).
>>Please note if you use offset and limit, getSize() will return the size
>>of
>> the re
Hi,
> I'd really like to avoid the need to rely on observation for keeping
> internal data structures in sync. It adds quite a bit of complexity
Well, having the index configuration distributed is what really adds
complexity :-) I think keeping a central list of all index configurations
simplifie
quot; wrote:
>Hi,
>
>On Tue, Sep 18, 2012 at 5:30 PM, Thomas Mueller wrote:
>>>First of all I think there shouldn't be just one single place in the
>>>repository where all index configuration should go.
>>
>> Hm, how would the query engine detect what
Hi,
>At query time, when it knows the main path constraint used in the
>query, it can walk down that path to detect which indexes are
>available and useful for resolving the query.
I guess we could make it work. It would make the query engine a bit more
complex, and some of the queries would get
Hi,
>First of all I think there shouldn't be just one single place in the
>repository where all index configuration should go.
Hm, how would the query engine detect what indexes are available? I think
keeping the index configuration at one place is the most simple solution,
and I don't currently
Hi,
>>About workspaces - I know we said we don't support workspaces currently,
>> but there still is ContentSession.getWorkspaceName(). Could we remove
>>this
>> method for now?
>Currently the workspace root and the repository root are the same
>thing, while we only support a single workspace. On
n) combine Root and ContentSession. But for
now I guess it's enough to add a comment in the Javadoc.
Regards,
Thomas
On 9/14/12 7:32 AM, "Thomas Mueller" wrote:
>Hi,
>
>>It would be better if the query engine used the same tree snapshot as
>>the rest of
Hi,
>The idea with the timeout sounds good, but what should we recommend an
>application to do if getSize() takes too long and returns -1?
>
>Imagine while paging search results, the first page query is fast enough
>(getSize() returns something), but the second is too long and now returns
>-1: sho
Hi,
>It would be better if the query engine used the same tree snapshot as
>the rest of the session. There shouldn't be any need to call
>getCurrentRoot().
This is actually what I expected that ContentSession.getCurrentRoot()
would provide me: I expected getCurrentRoot() would always return the s
Hi,
To read a node, the query engine currently uses:
session.getCurrentRoot().getTree(path);
The query engine calls this whenever it has to evaluate a property. It
turns out internally the getCurrentRoot() method always calls
MicroKernel.getHeadRevision(). I wonder if this is required, and i
, "Jukka Zitting" wrote:
>Hi,
>
>On Thu, Sep 13, 2012 at 10:22 AM, Thomas Mueller
>wrote:
>> Yes. Let's discuss the value now! 1000 sounds OK in general, however
>>there
>> is a potential performance problem.
>
>How about instead of a size limit w
Hi,
>return the correct size if the result set has fewer than
>something like 1000 entries. That should cover most practical cases
Yes. Let's discuss the value now! 1000 sounds OK in general, however there
is a potential performance problem. For Jackrabbit 2.x, if there are more
than a few millio
Hi,
>>(and getSize() would still return -1 I guess?)
>
>For backward compatibility I'd leave the behaviour "as unchanged as
>possible". That is, return -1 if the size is not quickly available.
Yes, that what I had in mind. The question is now, what exactly *is*
quickly available. I suggest that t
Hi,
The main question is still what the JCR API method getSize() should return.
A new method getSize(int max) is nice, and of course we can do that. But I
guess people will not use it in the near future because it's not part of
the JCR API.
Regards,
Thomas
On 9/12/12 8:06 PM, "Michael Marth
Hi,
>There's no need for the Oak API to reflect JCR in all its details.
Sure. First we need to define how the JCR API implementation is supposed
to behave. Based on that we can then still decide what the Oak API should
look like. The Oak API is (more or less) an implementation detail. Of
course t
Hi,
>As an alternative: we could use a separate method getSize(int max) which
Yes, that would work as well. I have added that to OAK-300. The
disadvantage is that it's a new API (not part of the JCR specification).
The two options I proposed don't require a new API.
Regards,
Thomas
Hi,
>>>2. The client does need to know the size, so it calls getSize() and
>>
>> I currently can't come up with a convincing use case - what is your use
>> case?
>
>Display the actual number of search results to the user?
Do you want to risk that the method getSize() takes 1.5 hours just to
disp
Hi,
I'm worried about queries that return a huge number of rows, for example 1
million nodes. If getSize() is supposed to return the correct result, it
could potentially take hours (when reading 100 nodes per second). I'm more
in favour of returning -1 if there are more than just a few rows (for
e
[
https://issues.apache.org/jira/browse/OAK-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445804#comment-13445804
]
Thomas Mueller commented on OAK-288:
> util class
That looks good to me.
>
[
https://issues.apache.org/jira/browse/OAK-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445785#comment-13445785
]
Thomas Mueller commented on OAK-28:
---
Thanks Chetan! Fixed in revision 137
[
https://issues.apache.org/jira/browse/OAK-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444801#comment-13444801
]
Thomas Mueller commented on OAK-288:
> proper reporting unit test failures
If t
[
https://issues.apache.org/jira/browse/OAK-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444797#comment-13444797
]
Thomas Mueller commented on OAK-288:
I'd like to keep the internal DSL style
[
https://issues.apache.org/jira/browse/OAK-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439367#comment-13439367
]
Thomas Mueller commented on OAK-270:
I agree (with both Angela and Michael). For a
[
https://issues.apache.org/jira/browse/OAK-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438565#comment-13438565
]
Thomas Mueller commented on OAK-264:
Here the proposed patch. The project oak-i
[
https://issues.apache.org/jira/browse/OAK-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-264:
---
Priority: Minor (was: Major)
Issue Type: Improvement (was: Bug)
> MicroKernel.diff
Thomas Mueller created OAK-264:
--
Summary: MicroKernel.diff for depth limited, unspecified changes
Key: OAK-264
URL: https://issues.apache.org/jira/browse/OAK-264
Project: Jackrabbit Oak
Issue
Thomas Mueller created OAK-262:
--
Summary: Query: support pseudo properties like jcr:score() and
rep:excerpt()
Key: OAK-262
URL: https://issues.apache.org/jira/browse/OAK-262
Project: Jackrabbit Oak
[
https://issues.apache.org/jira/browse/OAK-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-262:
---
Component/s: core
Assignee: Thomas Mueller
Issue Type: Improvement (was: Bug)
> Qu
Hi,
>>On debugging issue is shown at char 183 and is around
>> jcr:like(rep:principalName,(*)'%%') . So it appears that
>> XPathQueryEvaluator.visit(XPathQueryBuilder.NodeCondition) [1] should
>>add
>> '@' before appending the rep:principalName property name as its a
>>property
>> Condition
Yes,
Hi,
Thanks a lot! I'm currently working on trying to support such queries in
the XPathToSQL2Converter. I'm not sure yet how much work this will be,
let's see.
Is the query really using '**' and '%%'? If yes are there any nodes that
contain '**', or is this just test data (just wondering)?
Regard
[
https://issues.apache.org/jira/browse/OAK-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437877#comment-13437877
]
Thomas Mueller commented on OAK-260:
The main problems should be fixed in r137
Thomas Mueller created OAK-260:
--
Summary: Avoid the "Turkish Locale Problem"
Key: OAK-260
URL: https://issues.apache.org/jira/browse/OAK-260
Project: Jackrabbit Oak
Issue
Hi,
Actually, equalsIgnoreCase isn't a problem. The problem is just
String.toLower() and String.toUpper(). See also:
http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug
So this returns true, as required:
Locale.setDefault(new Locale("tr"));
System.out.println("Ii".equalsIgnor
Hi,
True, we need to fix that. I guess we also need to fix it in Jackrabbit
2.x. To find all Turkish locale bugs, would it make sense to run automated
tests (additionally) with the Turkish locale?
Regards,
Thomas
On 8/20/12 11:02 AM, "julian.resc...@gmx.de" wrote:
>I just stumbled upon equals
Hi,
>In general the repository shutdown should IMO *never* block for any
>background tasks. A "kill -9" on a JVM process should IMHO be considered a
>valid way to shutdown a repository running inside the JVM, so there's
>nothing that the repository should expect a background task to finish in
>tim
[
https://issues.apache.org/jira/browse/OAK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13435156#comment-13435156
]
Thomas Mueller commented on OAK-245:
>> Class.forName("org.h2.Driver
Thomas Mueller created OAK-241:
--
Summary: QueryEngine.executeQuery needs a session parameter
Key: OAK-241
URL: https://issues.apache.org/jira/browse/OAK-241
Project: Jackrabbit Oak
Issue Type
Hi,
I know this isn't related directly to "in-memory microkernel", but it
seems to me the reason to propose an "in-memory microkernel" is to improve
performance. Unless I misunderstood the mail?
As for Jackrabbit 2.x read and write performance, I found that JCR-2857
helps, specially for larger r
[
https://issues.apache.org/jira/browse/OAK-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-239:
---
Priority: Minor (was: Major)
> MicroKernel.getRevisionHistory: maxEntries behavior should
Thomas Mueller created OAK-239:
--
Summary: MicroKernel.getRevisionHistory: maxEntries behavior
should be documented
Key: OAK-239
URL: https://issues.apache.org/jira/browse/OAK-239
Project: Jackrabbit Oak
Hi,
Sorry I didn't have time to review last week. You wrote "The vote is open
for the next 72 hours" on August 7. I don't know why we have the 72 hour
window, but I guess we need a new vote now?
Regards,
Thomas
On 8/13/12 11:47 AM, "Alex Parvulescu" wrote:
>hi,
>
>there is an ongoing vote to
Hi,
I think the problem you want to solve is having a high performance storage
subsystem. There are multiple ways to solve this.
One is to write a new in-memory microkernel. Another is to use a very big
cache, and write in a background thread. This would also work if the data
doesn't fit in memor
[
https://issues.apache.org/jira/browse/OAK-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431133#comment-13431133
]
Thomas Mueller commented on OAK-225:
Let me rephrase it: I'm not convinced it&#
[
https://issues.apache.org/jira/browse/OAK-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431099#comment-13431099
]
Thomas Mueller commented on OAK-225:
I tried to add the comment on OAK-225 yeste
[
https://issues.apache.org/jira/browse/OAK-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430992#comment-13430992
]
Thomas Mueller commented on OAK-225:
In revision 1370294 the query is converted to a
[
https://issues.apache.org/jira/browse/OAK-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422310#comment-13422310
]
Thomas Mueller commented on OAK-189:
Well, this is not about checked versus unc
Thomas Mueller created OAK-209:
--
Summary: BlobStore: use SHA-256 instead of SHA-1, and use two
directory levels for FileBlobStore
Key: OAK-209
URL: https://issues.apache.org/jira/browse/OAK-209
Project
[
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421398#comment-13421398
]
Thomas Mueller commented on OAK-178:
Request for feedback:
Currently the i
[
https://issues.apache.org/jira/browse/OAK-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421344#comment-13421344
]
Thomas Mueller commented on OAK-182:
I think I misunderstood how the ValidatingEd
[
https://issues.apache.org/jira/browse/OAK-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-182.
Resolution: Fixed
> Support for "invisible" int
[
https://issues.apache.org/jira/browse/OAK-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421322#comment-13421322
]
Thomas Mueller commented on OAK-182:
> I think the ValidatingEditor shouldn&#
[
https://issues.apache.org/jira/browse/OAK-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-182:
---
Attachment: OAK-182-b.patch
This patch adds a class NodeStateUtils with a static function isHidden
301 - 400 of 616 matches
Mail list logo
