Value Types are lost after sending data over the driver

Value Types (Integer and Float) are lost after sending data over the driver,

If I create Node with 4 properties:

• int : 1
• long : 2L
• double : 3.0
• float : 4.0f I would expect same property types to be returned when retrieved from the server via driver.

Neo4j Version: 3.1 Operating System: Win7 API: neo4j-java-driver 1.1.0

Steps to reproduce

1. Create Node
2. Assign 4 properties of different types (int, long, double, float)
3. Retrieve each value and evaluate it’s type against the initial type

Expected behavior

property creation type is equal to retrieved property type.

Actual behavior

int type is retrieved as long float type is retrieved as double

Findings

Well, I can see you’ve got ‘value adapter’ for IntegerValue which in reality combines two types - long and int, and FloatValue - both of which extend NumberValueAdapter. When I’ve created Node and am setting properties - it goes through Values.value(propertyValue) and transforms my Integer into:

    private final long val;
    public IntegerValue( long val ) {
        this.val = val;
    }

and Float into:

    private final double val;
    public FloatValue( double val ) {
        this.val = val;
    }

This makes me sad. So On the server I end up always only persisting long and double typed properties, never int or float. When I retrieve this properties from the server using Node.asMap() -> I again (not surprised) get back IntegerValue and FloatValue which are “transformed” (just returns their val) via NumberValueAdapter.asObject() -> asNumber(); respectively into Long and Double.

What is important - this is not compatible with Official Embedded DB and REST

[technige]

Closing issue as now being dealt with separately through customer support channel.

[bHacklv]

@zhenlineo Our application acts as a ‘middleware’ between Neo4j and complex system (which has sub-systems, etc that write and expect to receive correct types). Though I gave an example of what sort of Class and its types we would have - option 1 and option 2 is a no go for us, as at our stage we don’t have class models and still operate in abstract class fashion (Nodes, Rels, etc.). So there would be nothing to map to and we still return properties as Object type (expecting them to have at-persist-time types).

I suppose we would have to stay with our own ‘driver’ solution then.