Hello Vijay,
pls continue this thread on the user-list because it is clearly not a
dev-list question.
Also I hope you do realize your question is kind of vague...are you
talking about how large one single binary data blob can be, or are you
referring to how many nodes Jackrabbit can handle? Obvi
[
https://issues.apache.org/jira/browse/JCR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561599#action_12561599
]
Claus Köll commented on JCR-1334:
-
do you have any ideas to solve that problem ?
> Deadlock
Hi,
What is maximum amount of data that can be handled
efficiently by Apache Jackrabbit?
Regards,
Vijay Makhija
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://m
[
https://issues.apache.org/jira/browse/JCR-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aidan O'Loan updated JCR-1339:
--
Attachment: ManageableCollectionUtil_JCR-1339.txt
Proposed patch to support ManagedHashMap
> ManageableC
ManageableCollectionUtil doesn't support Maps
-
Key: JCR-1339
URL: https://issues.apache.org/jira/browse/JCR-1339
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affect
Have you guys looked at how Hadoop's Hbase is designed? I wonder if
perhaps the bigtable or hbase architecture may help?
http://wiki.apache.org/hadoop/Hbase/HbaseArchitecture
I am still wavering on is jcr a database perhaps? I wonder if there is a
need to invent a new storage mechanism when th
Carsten Ziegeler wrote:
Yes, I more or less agree, but :) I can use ORM without mapping the PK,
for example in just reading use cases or I can even add new objects to
the database if the PK is auto generated. Updating and removing are the
things that do not work, but that's fine for me :)
However
ItemImpl.save(1251) | /: unable to update item.
Key: JCR-1338
URL: https://issues.apache.org/jira/browse/JCR-1338
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affe
[
https://issues.apache.org/jira/browse/JCR-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561448#action_12561448
]
Ard Schrijvers commented on JCR-1337:
-
When per-document payloads and unique doc ids are
Optimize first execution queries for DescendantSelfAxisWeight/ChildAxisQuery
Key: JCR-1337
URL: https://issues.apache.org/jira/browse/JCR-1337
Project: Jackrabbit
I
[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ard Schrijvers resolved JCR-1196.
-
Resolution: Fixed
Fix Version/s: 1.4.1
Assignee: Ard Schrijvers
I close this issue
[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561441#action_12561441
]
Ard Schrijvers commented on JCR-1196:
-
Hello Martin,
I reproduced your problems, but th
> > > > reusing an already indexed and analyzed document might
> be a handy
> > > > lucene feature anyway.
> > >
> > > Agreed. Perhaps something to follow up with the Lucene guys.
> >
> > I'll ask on the lucene user-list and see wether I get some input.
At the lucene user-list Karl Wettin poin
Hi,
On Jan 22, 2008 3:07 PM, Angela Schreiber <[EMAIL PROTECTED]> wrote:
> > -1 You're proposing a switch from CTR to RTC.
>
> i'm not proposing this. you are mistaken.
ACK, understood. Your original comment seemed like a general
observation about all changes.
> but i expect that we are careful
>From the lucene dev list:
Jukka pointed me lately to per-document payloads. I just happened to
read the mail below on the lucene dev-list. Might be an interesting
development for us to follow. Think the hierarchy resolver might benefit
from uid doc ids (where we now loose the computed cached hie
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-1331:
Component/s: jackrabbit-spi-commons
adjusting affected projects.
> Inproper deprecation of Locked class
> --
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561332#action_12561332
]
angela commented on JCR-1331:
-
> Unless anyone has further objections I'll re-commit the patch in
hi jukka
-1 You're proposing a switch from CTR to RTC.
i'm not proposing this. you are mistaken.
but i expect that we are careful regarding code
that is more than an internal detail. and that
we don't make changes forth and backand in this
case waiting a couple of
days would not have done
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561314#action_12561314
]
Jukka Zitting commented on JCR-1331:
> Name, NamespaceResolver and NamePathResolver.
My
Hi,
[Branching the general issue from Jira]
On Jan 22, 2008 12:54 PM, angela (JIRA) <[EMAIL PROTECTED]> wrote:
> but i expect that we have a minimal response time to give everybody
> the time to look at a patch. apart from that i expect that patches and
> suggestions are really looked at, before
Bug in duplicate mapping check
--
Key: JCR-1336
URL: https://issues.apache.org/jira/browse/JCR-1336
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Re
[
https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved JCR-1335.
-
Resolution: Fixed
Fixed with revision 614177.
> bad assumptions on QueryResult.getIterator() sema
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561298#action_12561298
]
angela commented on JCR-1331:
-
> was there some other reason than the Name dependencies for movin
Hi,
I fully agree with Marcel: in my view a mix of "journal" and "store"
would be the best solution. The "store" solution has the advantage
that unused items can be deleted without affecting other items (or
leave unused space in a file).
The line between "journal" and "store" can be fluid: an ite
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1331:
---
Attachment: JCR-1331.patch
> sorry. i don't agree on this change.
Ah, I'm sorry for jumping the fox he
[
https://issues.apache.org/jira/browse/JCR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561278#action_12561278
]
Marcel Reutegger commented on JCR-1334:
---
Prepare and commit is indeed called using diff
Angela Schreiber wrote:
Marcel Reutegger wrote:
Carsten Ziegeler wrote:
Now, this may be a dumb question, but why this move?
that was probably by mistake.
i don't think so. and it was made on intention.
Ok, let me explain my use case: the Node.lock() method does not
guarantee that I ge
Angela Schreiber wrote:
that was probably by mistake.
i don't think so. and it was made on intention.
ok, I'll rephrase: 'that was probably a mistake' ;)
regards
marcel
[
https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reopened JCR-1331:
-
sorry. i don't agree on this change.
and: jukka, i would expect that you wait at least for one day before you
make suc
hi julian
Julian Reschke wrote:
- is anybody looking at these?
- do we have JIRA issues (except JCR-1293 which seems to be something
different)?
i have been looking at the problem described in
JCR-1293 and i assume that all the occasional
failing tests are a result of the same problem
(the on
Hi Jukka,
how about a mix of both, where both engines contribute what they can do best.
the 'journal' engine is IMO best suited for a large number of unique and small
records. large number because it requires less individual files, compared to the
'store'. unique because it cannot detect dupli
Marcel Reutegger wrote:
Carsten Ziegeler wrote:
Now, this may be a dumb question, but why this move?
that was probably by mistake.
i don't think so. and it was made on intention.
we should probably clarify what classes belong to jcr-commons and
spi-commons.
that has already be done du
32 matches
Mail list logo
