activegraph: `skip` parameter shouldn't vary by the number skipped

If you have pagination of 50 then the parameter shouldn’t be skip_50 because the query doesn’t get cached

About this issue

  • Original URL
  • State: open
  • Created 9 years ago
  • Comments: 45 (20 by maintainers)

Most upvoted comments

I just want to say thank you to @subvertallchris and @cheerfulstoic for spending your time maintaining this great gem. Without you many Ruby developers would have way more effort of using Neo4j.

@levidamian If you need exactly this use-case then you should use a database that is built for this use-case. Neo4j has many applications with connected data where it excels because it was built for that. At some point we will cover more use-cases, but right now we focus our capacity on the things that benefit the majority of our users and customers. Sorry if that’s not enough for you.

To make this absolutely clear because I’m not sure if you saw it:

We have are not Neo Technology (the creators of Neo4j). We are volunteers maintaining the neo4j.rb Ruby gems because we happen to really like Neo4j. We spend our free time working on this gem. We enjoy responding to issues to the best of our ability and fixing issues as quickly as we can given our schedules. Anything that Chris or I have said we offer as personal advice and it should not be taken as coming from Neo Technology as a company.

We’ve tried to offer suggestions and advice on what we would do in your shoes. If those aren’t sufficient I’m sorry that we couldn’t be of more help. If you contact Neo Technology through their official channels they may have other suggestions.

As far as we know as outsides to the product development of Neo4j this is an issue that the company is aware of and interested in fixing. It sounds like various remedies are on the roadmap for Neo4j.

  1. The only query that can be changed to operate more efficiently is the count, which we discussed changing and I can patch if you can provide the total.
  2. That’s not something we have the power to do.
  3. We cannot be responsible for opening issues for you. We could have directed you there in the first place instead of offering suggestions to work around the issue. I’m sorry that you find that offensive, but we volunteer a lot of our time to help users and have never had someone find feedback so objectionable.