{"action":"created","issue":{"url":"https://api.github.com/repos/neo4j/neo4j/issues/6588","repository_url":"https://api.github.com/repos/neo4j/neo4j","labels_url":"https://api.github.com/repos/neo4j/neo4j/issues/6588/labels{/name}","comments_url":"https://api.github.com/repos/neo4j/neo4j/issues/6588/comments","events_url":"https://api.github.com/repos/neo4j/neo4j/issues/6588/events","html_url":"https://github.com/neo4j/neo4j/issues/6588","id":138046326,"number":6588,"title":"Feature request: Hierarchical indexes","user":{"login":"rationalism","id":813306,"avatar_url":"https://avatars.githubusercontent.com/u/813306?v=3","gravatar_id":"","url":"https://api.github.com/users/rationalism","html_url":"https://github.com/rationalism","followers_url":"https://api.github.com/users/rationalism/followers","following_url":"https://api.github.com/users/rationalism/following{/other_user}","gists_url":"https://api.github.com/users/rationalism/gists{/gist_id}","starred_url":"https://api.github.com/users/rationalism/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rationalism/subscriptions","organizations_url":"https://api.github.com/users/rationalism/orgs","repos_url":"https://api.github.com/users/rationalism/repos","events_url":"https://api.github.com/users/rationalism/events{/privacy}","received_events_url":"https://api.github.com/users/rationalism/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-03-03T01:31:41Z","updated_at":"2016-03-04T04:04:11Z","closed_at":null,"body":"Suppose there's a neo4j graph with a node for every person in the US (not exactly my use case, but close enough). Each person has both a name and a city. I want to do a fast lookup of the John Smith in Springfield, but there are (say) 10,000 cities in the graph, each with 30,000 people, and there are also 30,000 John Smiths. If I create a neo4j index on person:name, then neo4j needs to do a linear scan over the 30,000 John Smiths; if I create a neo4j index on person:city, then neo4j does a linear scan over all 30,000 people in Springfield; and both of these are annoyingly slow.\r\n\r\nMy current solution is to create a separate label for each city - person_springfield, person_boston, person_buffalo, and so on - and make a separate index for each of them, but this seems ugly and potentially prone to problems, and I also have to add a redundant \"person\" label to look up people across cities. Alternatively, I could have separate properties for \"name\", \"city\", and \"namecity\" (which stores the two strings concatenated) and put an index on those, but then each piece of data would be stored twice, and would have to be kept in sync manually. \r\n\r\nIt would be really great if neo4j had native support for nested/hierarchical indexes, allowing one to look things up by name and then by city (or vice-versa) within the same index. Relevant StackOverflow threads:\r\n\r\nhttp://stackoverflow.com/questions/20491371/index-on-multiple-properties-in-neo4j-cypher\r\n\r\nhttp://stackoverflow.com/questions/22498054/how-to-create-unique-constraint-involving-multiple-properties-in-neo4j\r\n\r\nhttp://stackoverflow.com/questions/18860415/neo4j-cypher-index-query\r\n\r\nhttp://stackoverflow.com/questions/12166283/performance-issues-while-creating-index-on-multiple-fields-in-spring-data-neo4j"},"comment":{"url":"https://api.github.com/repos/neo4j/neo4j/issues/comments/192089534","html_url":"https://github.com/neo4j/neo4j/issues/6588#issuecomment-192089534","issue_url":"https://api.github.com/repos/neo4j/neo4j/issues/6588","id":192089534,"user":{"login":"astesin","id":7247555,"avatar_url":"https://avatars.githubusercontent.com/u/7247555?v=3","gravatar_id":"","url":"https://api.github.com/users/astesin","html_url":"https://github.com/astesin","followers_url":"https://api.github.com/users/astesin/followers","following_url":"https://api.github.com/users/astesin/following{/other_user}","gists_url":"https://api.github.com/users/astesin/gists{/gist_id}","starred_url":"https://api.github.com/users/astesin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/astesin/subscriptions","organizations_url":"https://api.github.com/users/astesin/orgs","repos_url":"https://api.github.com/users/astesin/repos","events_url":"https://api.github.com/users/astesin/events{/privacy}","received_events_url":"https://api.github.com/users/astesin/received_events","type":"User","site_admin":false},"created_at":"2016-03-04T04:04:11Z","updated_at":"2016-03-04T04:04:11Z","body":"On Fri, Mar 4, 2016 at 5:28 AM, rationalism <notifications@github.com> wrote:\n> @astesin Neo4j has explicitly confirmed that legacy indexes are deprecated\n> and will be replaced. See this quote from a blog post from last week:\n>\n> \"Seriously, you should always use schema indexes whenever possible. Schema\n> indexes were added in Neo4j 2.0, and now with Neo4j 2.3, they have been\n> significantly improved. You can now do prefix queries based on indexes as\n> well as range queries,\n\nAgh, Ok, it wasn't possible with 2.2 at least. But see below:\n\n> and I hope we see more in the future on that. Our\n> long-term goal is leave legacy indexes behind entirely.\n>\n> There’s a story about that. When we first released Neo4j 2.0, we had\n> converted all the functionality of the legacy indexes into the schema\n> indexes, but we had done it really fast. That’s why we initially labeled the\n> older indexes as “legacy.”\n>\n> But there are cases when you still need legacy indexes. For example, if you\n> want to do full-text indexing, you can’t do that with schema indexes. Sorry.\n\nSo what do you think? Will they REALLY drop manual indexes and loose a\nfull-text ability entirely? Do you really believe this will happen\nanytime soon?\n\n> As we work to replace legacy indexes entirely (including for full-text\n> indexing),\n\nSomething makes me think that this will not be done at least until 4.0.\n\n> we’ve chosen to make legacy indexes a little bit hard to use. So\n> if you’re finding them difficult, that’s good, because one day, they’ll be\n> gone forever.\"\n\n...and you will loose the single present possibility to index\nrelationships(!) on their properties? This is damn unbelievable :)\n\nOk I'll personally stuck with Neo4j 3.* forever then :)\n\nWBR,\nAndrii\n"}}