Factor write_direct_dense out of Cython
#2109
Open
+111
−159
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ihnorton
requested changes
Nov 19, 2024
There was a problem hiding this comment.
This is because the np_to_tdb_dtype function (see here) cannot handle numpy arrays with multiple dtypes.
I think we need to dig in to this one more, because it doesn't exactly have multiple dtypes -- the dtype is a record type. Also the mem:// issue, see inline.
kounelisagis
force-pushed
the
agis/move-write_direct_dense-to-python
branch
from
7b7929c
to
bf869f3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR integrates the
write_direct_densefunctionality directly into Python'sDenseArray::write_direct, using only the pybind11/C++ bindings.Regarding test changes:Fortiledb/tests/test_hypothesis.py::test_bytes_npdf[np], the change fromuri = "mem://" + checked_path.path()touri = checked_path.path()was necessary to make it work. This is because, for example, a URI could be:mem:///var/folders/gw/5rx7wg1d6397n6nwy86qjf7c0000gn/T/tiledb-disktestcasepvi959vz/tmphgkelovb. The issue seems to be the use of///. I guess that speed was the primary concern for usingmem://.Fortiledb/tests/test_libtiledb.py::test_fixed_string, a change in the dtype of the numpy array was required. This is because thenp_to_tdb_dtypefunction (see here) cannot handle numpy arrays with multiple dtypes. This issue is expected to arise elsewhere in the codebase wherever this function is called with numpy arrays containing multiple dtypes. Addressing this limitation could be implemented in a future PR, as I believe it falls outside the scope of this one.