You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2007/10/09 14:46:50 UTC

[jira] Created: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

JCR2SPI does not provide actual size on RangeIterator.getSize()
---------------------------------------------------------------

                 Key: JCR-1166
                 URL: https://issues.apache.org/jira/browse/JCR-1166
             Project: Jackrabbit
          Issue Type: Improvement
          Components: SPI
            Reporter: Julian Reschke


Currently, JCR2SPI always returns -1 on RangeIterator.getSize().

This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.

Use case:

"The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "

To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.

Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela resolved JCR-1166.
-------------------------

    Resolution: Fixed

fixed rev: 599349  


> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela updated JCR-1166:
------------------------

    Fix Version/s: 1.4

julian, would that be suitable for you?

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela updated JCR-1166:
------------------------

    Attachment: JCR-1166.patch

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Priority: Minor
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Reschke updated JCR-1166:
--------------------------------

    Priority: Minor  (was: Major)

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: SPI
>            Reporter: Julian Reschke
>            Priority: Minor
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela updated JCR-1166:
------------------------

    Component/s:     (was: jackrabbit-spi)
                 jackrabbit-jcr2spi

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Priority: Minor
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545021 ] 

angela commented on JCR-1166:
-----------------------------

noe... you get the size immediately. but it may not be totally accurate if nodes are removed after accessing
the iterator (or if nodes are removed by somebody else and cachebehaviour is observation or if you refresh
the session after accessing the iterator).

in any case: if during iteration an invalid/removed item is encountered the effective size will be lower.
that may happen in any case. 
that's an built in consequence of the lazy iteration and not an effect of whatever size-value detection.

the only thing that changes: initially i thought that -1 would be more appropriate than a size value that is
not 100% correct.

angela

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544864 ] 

angela commented on JCR-1166:
-----------------------------

i would suggest modify the LazyItemIterator to apply the same logic as present currently in the query.NodeIteratorImpl:

- take the size of original collection as estimation for the number of Items available during iteration.
- recalculated the size if entries that cannot be resolved to Items are found during the iteration.

this would have the following benefits:
- if nothing changes in the meantime the size estimate is accurate
- no extra effort to calculate the size upon/before creating the iterator
- don't modify lazy behaviour of the iterator

drawback:
- size may shrink during iteration.


> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Priority: Minor
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545012 ] 

Julian Reschke commented on JCR-1166:
-------------------------------------

But that would still require to completely iterate through what the SPI implementation returned, right?

I would really prefer if we could avoid iterating through the children if all the caller wants to know is their number.
 

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela reassigned JCR-1166:
---------------------------

    Assignee: angela

> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (JCR-1166) JCR2SPI does not provide actual size on RangeIterator.getSize()

Posted by "angela (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545873 ] 

angela commented on JCR-1166:
-----------------------------

for the record (translation of oral communication):

the problem julian is referring to is 2-folded:

1) the -1 return value of the RangeIterator implementation.
2) the fact that RepositoryService.getChildInfos returns an Iterator -> thus the caller needs to iterate in order to
     detect the size. That could be improved thus making not only the ItemIterator lazy but also the code that
     populates the hierarchy.

Let's put 2) to a separate SPI issue. vale?

If nobody object i'm going to solve this issue as suggested.

angela


> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
>                 Key: JCR-1166
>                 URL: https://issues.apache.org/jira/browse/JCR-1166
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Julian Reschke
>            Assignee: angela
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-1166.patch
>
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to simply iterate through the whole list when what they really want is simply the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having to open up the NT_FOLDER and count all the members (and I assume load them into memory) "
> To make this happen we probably need to move away from simple Iterators on the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.