Updates: negative IDs

[ChristianGruen]

Update operations will eventually lead to negative node IDs. Possible solutions:

1. reject update operation if id leads to overflow
2. automatically optimize node ids before carrying through updates
3. long term (and, possibly, additionally to 1. or 2.): increase node id range from 31 to 63/64 bits

[LukasK]

1. Rejecting updates would be the simplest solution - if the number of new nodes introduced by the update consumes more IDs than possible, the update is rejected.The predicted # of IDs that are needed might differ depending on the interface (Commands, XQuery, ...) and optimizations/substitutions. Anyways, there is a need for a common structure where this can be checked.
2. Under what circumstances can 'old' IDs (IDs that have been used at some point, but are no longer used) be reused for new nodes? Are there any constraints? Again, a common structure is needed that knows about possible ID's.

Maybe it would be convenient to start with a solution for (1.) as ID's can always run out no matter what. This solution could then be extended with (2.). First step would be to identify the locations/layers where the problem can arise and how we can 'connect' them ... Maybe the AtomicUpdatesList? What about smaller/simple updates then?

[ChristianGruen]

Database is now optimized (IDs are re-enumerated, values indexes are recreated) if node id turns negative.