Hi, I document here my findings about pagination over relations. There are four 1-N relation types: LINKMAP, LINKSET, LINKLIST and LINKBAG. They seems to be stored as a list of rids right inside vertex/document (which is cool). LINKMAP, LINKSET, LINKLIST are loaded all at once when you ask for corresponding document/vertex fields - this makes them unusable to store large number of entries. BTW in my testing I found that 10000 links to empty documents takes only 170KB. LINKBAG on the other side can be partially loaded and potentially contain infinite number of entries.
Unfortunately all these goodies completely useless when you want to display paginated list. MAP, SET and LIST cannot be used since you will have to load entire collection, sort it and only then display some small portion of it. LINKBAG does not maintain order so it is also useless. The only method which I can think of is to use “relational” way of doing things. 1. Add “foreign key” aka "one directional link" from child to parent. CREATE LINK parent FROM Child.parentId TO Parent.rid 2. Create SB-Tree index on “child” vertex/document which will store entries in correct order. Something like this: CREATE INDEX xyz ON Child (ParentId, SortKey) NOT UNIQUE Since this is SB-Tree index hopefully index data will be sorted by “ParentId" and then “SortKey" which is exactly the order we need to display in a web page. 3. Select child entries from index which match your parent and ordering/sorting criteria. SELECT FROM INDEX:xyz WHERE ParentId = ? and SortKey > ? LIMIT PAGE_SIZE > On 19 мая 2015 г., at 19:03, Stefán <[email protected]> wrote: > > Hi, > > You can, if all the information exist on the edge, create that index on out, > date_created (the composition you propose will not give all the speed you > could get). > > I though you were talking about the date_created belonging to the vertex > (rather than the edge) but I understand now that you are talking about the > date that the relationship was created. > > Regards, > -Stefán > > > On Tuesday, 19 May 2015 15:19:52 UTC, Andrey Verbin wrote: > Hi Stefan, > > I was thinking that one way I can do it is to create sorted index on > (user_id, follower_id, date_created) and then select PAGE_SIZE entries form > it. Rest is easy - fetch selected entries and pass them to web page for > rendering. I’m still not sure if this is practical so any advice from > community will be helpful. > > Thanks, > Andrey > >> On 19 мая 2015 г., at 17:02, ste...@ <>activitystream.com >> <http://activitystream.com/> wrote: >> >> Hi, >> >> As far as I know there is no way to do that without: >> - Scanning all the "incoming classes" edges >> - Fetch the edges + vertexes >> - Keep them all in memory while they are being sorted >> - Return the top n edges/vertexes >> >> This happens behind the scenes and is not problematic on the query side but >> it is on the performance side. >> >> This is one of the issues we have come across when working with dense graphs >> and the changes, needed to fix this, are on the backlog. >> >> I would love fore someone to tell me that I'm terribly wrong here. >> >> Regards, >> -Stefan >> >> >> On Monday, 18 May 2015 14:58:17 UTC, Andrey Verbin wrote: >> Hi there! >> >> Let say I'm building something like Twitter. There is a User with 20000 >> followers modeled as a relationships between User and Follow classes. Every >> user reference N Follow instances which in turn has a link to follower user >> and also creation date. I want to display paginated list of followers but >> not sure how to do it with OrientDB. What would be the best way to display >> paginated list of such followers sorted by creation date? >> >> Thanks >> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "OrientDB" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe >> <https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe>. >> To unsubscribe from this group and all its topics, send an email to >> orient-databa...@ <>googlegroups.com <http://googlegroups.com/>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > > --- > You received this message because you are subscribed to a topic in the Google > Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe > <https://groups.google.com/d/topic/orient-database/5HXM9ysEIsE/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- --- You received this message because you are subscribed to the Google Groups "OrientDB" 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.
