Up (curious about the validity of the approach in my last message).

Thanks
Thomas

On Saturday, September 13, 2014 7:23:49 PM UTC+8, [email protected] 
wrote:
>
> What about this approach: if I want to get a paginated list of such nodes
> (n {id:"...", name:"...", someProperty:"..."})
> ordered by name, I could add a composite property namesort = name + id (I 
> guess that can be done automatically with a plug-in).
>
> Then I could query my list like
> MATCH (n:NodeType)
> WHERE n.someProperty = "some_value" AND namesort > 
> "last_result_of_previous_page"
> ORDER BY namesort
> RETURN n
>
> Thomas
>
> On Saturday, September 13, 2014 4:24:42 PM UTC+8, Michael Hunger wrote:
>>
>> Hi Thomas,
>>
>> Sure, what you then would do is to move the "limit" back to the limit 
>> clause
>>
>> Match (:Node {id:"unique-string"})-[:NEXT*1..]->(m)
>> WHERE m.prop = "value"
>> Return m
>> limit 20
>>
>> We'll add using indexes for ordering at some point but I'm not sure when 
>> and how.
>>
>> Michael
>>
>> On Sat, Sep 13, 2014 at 2:53 AM, <[email protected]> wrote:
>>
>>> Thanks Michael for your answer.
>>>
>>> If I understand correctly, your method would require to manually 
>>> maintain a chain of relationships between my nodes, in the order of the 
>>> field I want the results to be ordered by, right?
>>> Which means, if I want my paginated results to be ordered by "name", I 
>>> need to manually chain:
>>> (n1 {name:"a"})-[:NEXT]->(n2 {name:"aa"})-[:NEXT]->(n3 {name:"b"})-...
>>>
>>> There are some examples in the graph-databases book (free pdf on 
>> graphdatabases.com) on how to maintain such an list automatically on 
>> insert of new data.
>>
>> Michael
>>  
>>
>>> Would that work if I also wanted to filter the results with a WHERE 
>>> clause on some other field of my nodes? I guess it would somehow break the 
>>> chain...
>>>
>>> Cheers
>>> Thomas
>>>
>>> On Saturday, September 13, 2014 3:20:48 PM UTC+8, Michael Hunger wrote:
>>>>
>>>>
>>>>
>>>> Sent from mobile device
>>>>
>>>> Am 13.09.2014 um 05:31 schrieb [email protected]:
>>>>
>>>> Hi everyone,
>>>>
>>>> (sorry for the long post to follow!)
>>>>
>>>>
>>>> No worries
>>>>
>>>>
>>>> We have an existing platform relying on CouchDB (Cloudant, actually) 
>>>> and I'm evaluating a potential migration to Neo4j. The good thing with 
>>>> having an existing version is that I've already been through many 
>>>> pitfalls, 
>>>> so now I can consider them with Neo4j. One of them is *pagination*.
>>>>
>>>> CouchDB has a 'skip' feature that is similar to Neo4j. The doc clearly 
>>>> states that it should not be used for pagination, because it incurs 
>>>> potential performance issues when skipping lots of large pages (if you 
>>>> take 
>>>> 10 items by skipping 10, the DB will still fetch 20 and return the last 
>>>> 10).
>>>>
>>>> *So first question*: is it the same with Neo4j?
>>>>
>>>>
>>>> Yes. In embedded mode you can keep the result open though as well as on 
>>>> the remote endpoint where you can within a tx can continue to read
>>>>
>>>>
>>>> In case it is (and I believe it is!), I would like to see whether 
>>>> CouchDB's approach to pagination would be applicable. The strategy here is 
>>>> to fetch n+1 items, and pass the last one as a cursor/bookmark than will 
>>>> be 
>>>> used as a starting point for the next query. This sounds easy, but gets 
>>>> tricky if you order by a field that is not unique. Let me take an example.
>>>>
>>>> Say I have this kind of node: 
>>>> (:Node {id:"unique-string", name:"not-unique-string"})
>>>>
>>>> *My second question is*: if I want to query these nodes, ordered by 
>>>> name, is there a way to implement the cursor technique I mentioned before?
>>>>
>>>>
>>>> In a graph you can link these nodes in an ordered list by name and then 
>>>> follow the link
>>>>
>>>> For the next page your starting node would be the last node of the 
>>>> previous result
>>>>
>>>> Match (:Node {id:"unique-string"})-[:NEXT*1..20]->(m)
>>>> Return m
>>>>
>>>> For the next page you pass in the last id
>>>>
>>>>
>>>> Also, *subsidiary question*: I've read that 'order by' incurs a full 
>>>> scan, but is it also the case if I index the targeted field?
>>>>
>>>>
>>>> Yep, right now it is for the normal order by clause
>>>>
>>>>
>>>> Thanks all for helping me get familiar with that exciting platform!
>>>> Thomas
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Neo4j" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Neo4j" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to