Issue 1:
The problem

Neo4J version: 3.4.5 (community)

Operating System: Ubuntu 16.04

API/Driver: Python driver 1.6.2

When a node string property participates in an index. Neo4J imposes a (reasonable) limit on its byte length. However, sometimes, even if one trims the string length to that limit, the transaction does go ahead, no problem is reported but the database is left at an unusable state from which it has to be recovered by a restart.

The specific question I have about this issue is about a clarification of the 4095 bytes limit because if I trim at 4095 characters, the query does go ahead gracefully but still leaves the database at an unusable state.

Is there anything else that might be added to this key internally that has to be taken into account?

Currently, I am trimming at 4000 bytes which is even lower than keyValueSizeCap (4047) but there are still test cases which fail :(

I do not want to empirically lower this limit until I get no errors in my test cases, but rather I would like to understand how to determine the limit at which to trim an indexable property so that I do not have any errors. This will also help a lot with an effective solution for the validation of neomodel's StringProperty.

Reproducing the problem

A much more detailed presentation of the problem with test cases of predictable and unpredictable behaviour is available in this repository.

Expected behaviour

If the node property does not participate in an index, Neo4J has no problem in storing attribute values that may even be as big as 8kB.

Rather than throwing an exception which halts the whole process, would it be possible to consider specifying that in the case of indices, only the first ~4kB of the string's byte stream will participate in the key?

This means that if two strings happen to have the first N bytes identical, they would be considered as being the same even if their "ending" is different. (e.g. "Hello Neo4J" and "Hello" with key_size=5). This could be specified in the documentation around the node properties.

In this way, a property can still store long(ish) strings if required.

Note: The data I am dealing with were not expected to have such long values and in samples of hundreds of thousands of data items, just 2 happen to have such long values. We are talking about very rare occurrences but still possible. This indexing requirement means that I have to find an alternative way of both indexing the attribute and retaining its complete value which I will have to process at some point. I do not mind at all if duplicates are flagged just on the first ~4kB of the string because in my use case, if the first 4kB are the same, it is very likely that this is indeed the exact same value. But I cannot just store the trimmed value, I have to store both the trimmed (for the purposes of the indexing) and the non-trimmed (for the purposes of analysis) values. This is the motivation behind this request, rather than being able to store arbitrarily long pieces of text on Neo4J (which would not be good practice anyway).

Actual behaviour

The server is left in an unusable state which necessitates a restart (or sometimes, even a complete wipeout of the database directory).

Issue 2:
Add node.prop.indexOf('str') and rel.prop.indexOf('str') so that one could then use SUBSTRING to get to a value in the property. See:

http://stackoverflow.com/questions/19830600/neo4j-getting-data-out-of-and-ordering-on-node-properties-when-the-property-h