this might be a weird question from the leftfield, but are we actually sure
that the existing data store concept is worth the trouble? afaiu it saves us
from storing the same binary twice, but leads into the DSGC topic. would it be
possible to make it optional to store/address binaries by hash (
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,
I separated the two because I think it's the responsibility of the query
engine to use multiple indexes based on cost when there is more than
one restriction on a filter. This is not implemented right now, but I think
we will have to do that anyway to efficiently execute this query:
//element
On 5.11.12 13:04, Thomas Mueller wrote:
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 r
On 5.11.12 12:57, Marcel Reutegger wrote:
Hi,
I noticed that we use ReadOnlyTree in various plugins even though the class
is in the oak core package, which I think should be considered implementation
internal.
I think it makes sense to move it to an spi package. WDYT?
Generally +1. But OTOH
On Tue, Nov 6, 2012 at 9:45 AM, Mete Atamel wrote:
> Hi,
>
> On 11/6/12 9:24 AM, "Thomas Mueller" wrote:
>
>>Yes. Somebody has to decide which revisions are no longer needed. Luckily
>>it doesn't need to be us :-) We might set a default value (10 minutes or
>>so), and then give the user the abili
Hi,
On Mon, Nov 5, 2012 at 4:42 PM, Alex Parvulescu
wrote:
> heh, it appears the maven repo sync is lagging behind
>
> take for example jackrabbit-core:
> travic ci maven repo has 2.5.0 as latest version 161 days old [0]
> maven central has 2.5.2 latest from 18 Sept [1]
That's probably just be
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,
On 11/6/12 9:24 AM, "Thomas Mueller" wrote:
>Yes. Somebody has to decide which revisions are no longer needed. Luckily
>it doesn't need to be us :-) We might set a default value (10 minutes or
>so), and then give the user the ability to change that, depending on
>whether he cares more about
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
10 matches
Mail list logo
