Great answer, I want to second that.
Esp. when sending in the last place in the chain where you want to continue.
New syntax would be this and I would also add the limit directly to the
path-expression (unfortunately not possible as parameter
> MATCH p=(n)-[:next*20]->(x) WHERE id(n) = {prev_id} RETURN x,length(p)
Michael
Am 06.03.2014 um 02:29 schrieb Craig Taverner <[email protected]>:
> Perhaps as a concrete example of what Chris is describing here, I can comment
> further.
>
> The original example had three properties to order on, isbn, titel, pubDate.
> The text 'and so on' implies more, but let's assume there are not too many
> more. If there are indeed a limited number of predictable parameters, then
> you can order once (in memory) during graph creation, and create
> relationships to persist the order. For example, the ordered books by isbn
> could have a structure like (a)-[:next_by_isbn]->(b)-[:next_by_isbm]->(c)...
>
> Paginating through this might be somewhat different than before, since you
> would be searching along a chain. I tested this with a dataset I had, and it
> works with a syntax like:
> MATCH (n:Device {key:{value}}), p=(n)-[:next*]->(x) RETURN x,length(p) SKIP
> {skip} LIMIT {limit}
>
> The column 'x' contains the nodes in order. I returned length(p) also just
> for interest, as it represents the global position in the chain.
>
> Of course, a better option would be to remember the ID of the last entry, and
> pass that as a starting node for the next, so the traversal does not have to
> start at the beginning. Then each page would not need the skip setting:
> START n=node({prev_id}) MATCH p=(n)-[:next*]->(x) RETURN x,length(p) LIMIT
> {limit}
>
> This should perform better for long chains, like yours.
>
>
> On Wed, Mar 5, 2014 at 7:19 PM, Chris Leishman <[email protected]> wrote:
> Hey Nikolay,
>
> So this is an interesting query: the thing that stands out the most to me is
> that this query isn't doing anything with relationships - it's not taking
> advantage of the graph. So all that's left for Neo4j to do is to begrudgingly
> walk through every single Book and put them in order for you. Over and over.
> That's not going to be very fun for it, and it's not going to do it any
> better than a relational db (which loves these long, boring walks).
>
> If you want to really let the graph shine, consider ways you can use
> relationships to relate nodes together - and then query on those. Then you'll
> get some of that awesome graph speediness.
>
> Cheers,
> Chris
>
>
> On Tuesday, March 4, 2014 12:02:38 PM UTC-8, Nikolay Artamonov wrote:
> Hi guys! )
>
> My graph consists nodes labeled as :Book. In application I have to present
> table of books in paged manner and with sorting capabilities by various
> properties, for example:
>
> MATCH (b:Book) RETURN b ORDER BY b.isbn SKIP {offset} LIMIT {booksPerPage}
> MATCH (b:Book) RETURN b ORDER BY b.title SKIP {offset} LIMIT {booksPerPage}
> MATCH (b:Book) RETURN b ORDER BY b.pubDate SKIP {offset} LIMIT {booksPerPage}
> // ... and so on...
>
>
> It is supposed to have very much books (100,000 and more).
>
> Questions:
>
> 1. Does execution of previous queries imply loading ALL books in memory and
> linear processing for further ordering?
> 2. What can I do to decrease memory consumption and performance of execution
> of such queries in Neo4j 2.0/2.1? (indexing or something else)
> 3. What is planned to improve this situation in future releases of Neo4j?
>
> I really loved Neo4j and graph databases and I don't want to switch back to
> RDBMS just to resolve data access pattern described above.
>
> Thanks!
>
> --
> 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/groups/opt_out.
>
>
> --
> 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/groups/opt_out.
--
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/groups/opt_out.
