Repository navigation
feat: build and read GUID vectors in bulk - #18
Merged
Merged
Conversation
A GUID vector could be read one boxed atom at a time, and built only the same way: VecElem covered the numeric types, so neither Value::vec nor as_slice took a GUID, and push and set refused one. A caller with a column of 16-byte keys had no bulk path in either direction. The core stores a GUID vector as contiguous 16-byte cells, and ray_vec_from_raw already takes RAY_GUID: it copies the cells and its null scan raises HAS_NULLS for an all-zero one. So [u8; 16] becomes a VecElem mapped to RAY_GUID, and the generic paths take a GUID column as they take an i64 one: Value::vec builds it with one memcpy, as_slice::<[u8; 16]>() borrows it without copying, and push and set are type-checked against it. Value::guid_vec and Value::guid_slice name the two bulk paths. Boxed reads already handled RAY_GUID, so get, iter and to_vec::<Option<Guid>>() see the null as None. Four tests in tests/containers.rs: the build and the zero-copy slice (the empty vector and type mismatches included), nulls from construction and boxed access, push/set/set_null, and a vector built from bytes formatting as the engine's own from the same text and surviving ser/de. The vector and GUID pages say how. cargo test --workspace passes on the release flavour and on the debug one with RAY_DFD=1; clippy -D warnings and fmt are clean.
This file contains hidden or 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
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.
A GUID vector could be read one boxed atom at a time, and built only the same way: VecElem covered the numeric types, so neither Value::vec nor as_slice took a GUID, and push and set refused one. A caller with a column of 16-byte keys had no bulk path in either direction.
The core stores a GUID vector as contiguous 16-byte cells, and ray_vec_from_raw already takes RAY_GUID: it copies the cells and its null scan raises HAS_NULLS for an all-zero one. So [u8; 16] becomes a VecElem mapped to RAY_GUID, and the generic paths take a GUID column as they take an i64 one: Value::vec builds it with one memcpy, as_slice::<[u8; 16]>() borrows it without copying, and push and set are type-checked against it. Value::guid_vec and Value::guid_slice name the two bulk paths. Boxed reads already handled RAY_GUID, so get, iter and to_vec::<Option>() see the null as None.
Four tests in tests/containers.rs: the build and the zero-copy slice (the empty vector and type mismatches included), nulls from construction and boxed access, push/set/set_null, and a vector built from bytes formatting as the engine's own from the same text and surviving ser/de. The vector and GUID pages say how. cargo test --workspace passes on the release flavour and on the debug one with RAY_DFD=1; clippy -D warnings and fmt are clean.