Deprecation timelines

Hi there, moving a conversation over from my 'intro' mail!

Hi Michael, we're not using a Lua "driver" as such, we just have a bunch of our own Lua code built around connecting to the /db/data/cypher endpoint via HTTP. I realise it might have been a while since some of these things have been deprecated, we just haven't had any compelling reason to upgrade for a long time; didn't want to move to an upgrade that would force us to rewrite a load of code, and had to spend a bunch of time on other non-Neo projects. Now we come back to it, and the apoc index stuff is more mature, we'd like to move to that, but there seem to be more deprecation notices and it seems a lot more like quite significant components we've relied on are going away, meaning we're going to need to rewrite code and change operational stuff at some point.

So, sorry if this is old news but is there a roadmap & timeline for when which things are going to get deprecated (i.e. which version, and a rough idea of when that will happen), and what LTS versions they'll last be in (if any)? For us the most important thing is to know when neo4j-shell, REST API and /db/data/cypher HTTP endpoints will go away. Seems like the REST API will be removed in v4.0 - is it the same for the Cypher HTTP endpoint and the shell? Can't seem to find any documentation at all about the last two.

Thanks! :blush:

The removals will happen latest in 4.0. Originally 3.5 was planned for the old endpoints, but it seems the documentation points to 4.0.

I assume you encapsulated the code to do the REST cypher calls, so you only have to update one method to the "new" API /db/data/transaction/commit,

See: Introduction - HTTP API

OK great, thank you Michael. Yes the Lua Cypher endpoint stuff is wrapped up in one place so that won't be a big deal. There is PHP code elsewhere that uses the old REST API client so that's going to need a complete rewrite, either to use the transactional endpoint directly or the (comparatively) more recent GraphAware client - but again it's wrapped in its own classes so shouldn't be too bad.

Do we have any idea when 4.0 is likely to arrive?


4.0 some time next year, not clear yet.

Thanks again Michael!

Appreciate your guidance, and sorry to keep bugging you :scream: I'm just trying to get 100% clear on what we need to do to get up to speed with everything we'll need to change in preparation for v4.0.

I've been looking through our codebase and we're using some other things underneath /db/data, including under /db/data/index/* and /db/data/batch. I think most of this can be replaced with apoc.index work - I'll have to spend a little time digging into it and will get back if I have any questions I can't work out the answers for.

In the meantime, should I assume that /db/data/transaction is the only HTTP endpoint which will remain? And therefore anything under .../index, ../batch, .../schema (etc) will be going away too, thus:

  "node" : "/db/data/node",
  "relationship" : "/db/data/relationship",
  "node_index" : "/db/data/index/node",
  "relationship_index" : "/db/data/index/relationship",
  "extensions_info" : "/db/data/ext",
  "relationship_types" : "/db/data/relationship/types",
  "batch" : "/db/data/batch",
  "cypher" : "/db/data/cypher",
  "indexes" : "/db/data/schema/index",
  "constraints" : "/db/data/schema/constraint",
  "transaction" : "/db/data/transaction", // <-- ONLY ENDPOINT REMAINING AT v4.0
  "node_labels" : "/db/data/labels",
  "neo4j_version" : "3.4.6"

Cheers :slight_smile:

Yes, that's the plan.

There are also procedures in the database for explicit indexes.

1 Like