[tae898]

Closes #142

Database._convert_args (src/arcadedb/core.py) sent every positional np.ndarray parameter through to_java_float_array, so on the JVM build an int or bool array arrived as a Java float[] (ints as floats, int64 past 2**24 rounded, bools as 1.0 and 0.0). Now only float arrays (query vectors) take that path; any other dtype goes through convert_python_to_java, which binds the list tolist() gives (Long for ints, Boolean for bools), the same as a Python list and the same as the native build, whose encoder sends non-float arrays as tolist().

Dtype mapping on the positional path: float kinds keep float[]; int8 to int64 and uint types bind as the list of Python ints (Long); bool as Boolean. I did not add int[]/long[] crossings, because the native build and the list form already bind a list and the engine converts it into ARRAY_OF_INTEGERS / ARRAY_OF_LONGS. The named-parameter and document-property paths already used convert_python_to_java and are unchanged.

Tests (tests/test_numpy_support.py, run on both builds): positional int8/16/32/64 and uint8 arrays bind as ints equal to the list form, an int64 array holding 2**53 + 1 is exact, a bool array stays boolean, int32 and int64 arrays inserted into ARRAY_OF_INTEGERS / ARRAY_OF_LONGS read back as ints, and the named-parameter and doc.set paths are pinned. The positional tests fail on the old code because [1, 2, 3] came back as floats (and 2**53 + 1 rounded); the property and named tests already passed and only guard against regression. Not run locally (tests run against a built wheel in CI).

🤖 Generated with Claude Code