Dense [<- write fails for 3D arrays ("Subarray should have num_dims * 2 values")

Hi,

When writing to a dense 3D TileDB array using bracket assignment ([<-), I get the following error:

Error: Subarray should have num_dims * 2 values: (low, high) for each dimension.

This was originally encountered through the TileDBArray Bioconductor package, but the error comes from the tiledb package's [<- method. I've also filed LTLA/TileDBArray#30.

Minimal reproducible example

library(tiledb)

# Create a dense 3D array
tmp <- tempfile()
dom <- tiledb_domain(dims = list(
    tiledb_dim("d1", c(1L, 10L), 10L, type="INT32"),
    tiledb_dim("d2", c(1L, 10L), 10L, type="INT32"),
    tiledb_dim("d3", c(1L, 10L), 10L, type="INT32")
))
schema <- tiledb_array_schema(dom,
    attrs=list(tiledb_attr("val", type="FLOAT64")),
    sparse=FALSE)
tiledb_array_create(tmp, schema)

# Write using [<- : FAIL
arr <- tiledb_array(tmp, query_type="WRITE")
arr[1:10, 1:10, 1:10] <- array(runif(1000), dim=c(10,10,10))
#> Error: Subarray should have num_dims * 2 values: (low, high) for each
dimension.
tiledb_array_close(arr)

# Note: selected_ranges works as a workaround (per #259)
arr2 <- tiledb_array(tmp, query_type="WRITE")
selected_ranges(arr2) <- list(cbind(1L,10L), cbind(1L,10L), cbind(1L,10L))
# ... but not sure how to combine with value assignment
tiledb_array_close(arr2)

Context

I'm developing DelayedTensor, a Bioconductor package for out-of-core tensor arithmetic. We'd like to use TileDB as a storage backend (via TileDBArray) for 3D+ arrays. The [<- method works for 2D, and the sparse write path (via data.frame) works for 3D, so this seems specific to the dense subarray write path.

This appears to be the same issue as #259, which was closed as completed in 2021. However, the error still occurs with tiledb 0.34.0.

Session info

R version 4.5.3 (2026-03-11)
Platform: x86_64-conda-linux-gnu
tiledb 0.34.0

@LTLA

Hi, I'm hitting multiple issues with [<- on dense arrays with a single attribute, as investigated by @LTLA in LTLA/TileDBArray#31. The behavior depends on ncol:

ncol	Behavior
1	No error, but data is silently not written
2	Works correctly
3	Error: misinterpreted as sparse triplets
4+	Works correctly

Minimal example:

library(tiledb)

tmp <- tempfile()
dom <- tiledb_domain(dims = list(
    tiledb_dim("d1", c(1L, 4L), 4L, type = "INT32"),
    tiledb_dim("d2", c(1L, 3L), 3L, type = "INT32")
))
schema <- tiledb_array_schema(
    dom,
    attrs = list(tiledb_attr("x", type = "FLOAT64")),
    sparse = FALSE
)
tiledb_array_create(tmp, schema)

# ncol=1: silent failure
arr <- tiledb_array(tmp, query_type = "WRITE")
selected_ranges(arr) <- list(cbind(1, 4), cbind(1, 1))
arr[] <- matrix(runif(4), 4, 1)
tiledb_array_close(arr)
arr <- tiledb_array(tmp, query_type = "READ")
arr[1:4, 1:3]$x  # all NaN
tiledb_array_close(arr)

# ncol=3: error
arr2 <- tiledb_array(tmp, query_type = "WRITE")
arr2[1:4, 1:3] <- matrix(runif(12), 4, 3)
# Error: Assigned data.frame does not contain all required
#   attribute and dimension columns.
tiledb_array_close(arr2)

Both selected_ranges() and direct [i,j] assignment show the same behavior, so this appears to be in the core [<- logic.

This is blocking the use of TileDBArray as a DelayedArray backend for 2D writes in my package (DelayedTensor).

Session Information

tiledb 0.34.0
R 4.5.3

@LTLA

To add to this, as @LTLA noted in LTLA/TileDBArray#31 (comment: LTLA/TileDBArray#31 (comment)), this is not just an edge case — it's a major problem for block processing. Any matrix where the block width or its remainder is 1 or 3 columns will trigger these bugs. This makes [<- effectively unusable as a general-purpose dense write interface for DelayedArray backends.

As you figured out, [<- method for dense arrays does not recognize all cases. See this part of [<- code that sets the subarray:

TileDB-R/R/TileDBArray.R

Lines 1533 to 1538 in 3760c68

    
           ## case of dense array with subarray writes needs to set the subarray 
        
           if (!sparse && !is.null(i) && !is.null(j) && length(allnames) == 1) { 
        
             if (!is.vector(i) || !is.vector(j)) message("'i' and 'j' should be simple vectors.") 
        
             subarr <- as.integer(c(range(i), range(j))) 
        
             qryptr <- libtiledb_query_set_subarray(qryptr, subarr) 
        
           }

I had similar issue when working with 1D dense time-series; eventually I opted to implement a custom [<- method that sets the subarray with type.

Thanks, this clarifies the root cause.

However, this is a blocking issue for using TileDB-R as a general-purpose backend for DelayedArray / block processing:

Even in 2D, [<- fails or silently corrupts data depending on block width (1 or 3 columns)
For 3D (and higher), the current implementation is effectively unsupported due to the subarray construction

Given this, I have two questions:

Is there any plan to generalize the dense [<- implementation to support arbitrary dimensions?
Or is the intended usage to avoid [<- and implement custom write logic using lower-level APIs?

From the DelayedArray backend perspective, a reliable dense write path is essential, so clarification on the intended direction would be very helpful.

Is TileDB-R still actively maintained?
Previously, I contacted TileDB through the form on your website:
https://www.tiledb.com
However, I never received any response.

I understand that open-source projects often rely on multiple contributors, but at the moment it is unclear whether anyone is responsible for this issue or whether it is currently being investigated.

I would simply appreciate any feedback or clarification regarding the status of this issue.

@kokitsuyuzaki

I concur with @kokitsuyuzaki.

As an example, this remains unanswered #855 (comment); I should also include the short interaction with TileDB forum and the direct e-mails.

Now that I made two repos (R6.tiedb, storr.tiledb) public which are based on tiledb-r client, I am keen to see the development to be resumed in this repo.

@stavrospapadopoulos Stavros, could you kindly offer/share any plans and direction for this repo?

Add TileDBArray backend support with workarounds for TileDB-R [<- bug

@cgiachalis

It has been almost 3 months since this issue was filed, with no response from TileDB maintainers. @cgiachalis's PR (#855) has also been unanswered for even longer.

If TileDB-R is no longer actively maintained, please make that explicit — for example, by archiving the repository or updating the README. That way, downstream developers like myself can stop waiting and move on to alternative approaches.

I maintain DelayedTensor, which depends on a reliable dense write path via [<-. This bug blocks TileDBArray as a backend for out-of-core sparse 3D+ tensor operations, which was our primary motivation for adopting TileDB.

Without a clear signal on the status of this project, we are unable to make informed decisions about our own roadmap.

@jdblischak

@jdblischak I noticed you've been the most recent contributor to this repository, maintaining the CI infrastructure. Could you shed any light on the current development status of TileDB-R?

Specifically, is there anyone at TileDB actively responsible for addressing bug reports and feature development, or is the project currently in maintenance-only mode?

Any insight would be appreciated — it would help downstream maintainers like myself decide how to proceed.

@jdblischak I noticed you've been the most recent contributor to this repository, maintaining the CI infrastructure. Could you shed any light on the current development status of TileDB-R?

Specifically, is there anyone at TileDB actively responsible for addressing bug reports and feature development, or is the project currently in maintenance-only mode?

Any insight would be appreciated — it would help downstream maintainers like myself decide how to proceed.

I understand your frustration. Unfortunately I do not have the knowledge nor the authority to speak on behalf of TileDB in regards to the future plans for this repository. As you correctly noticed, my responsibility is limited to maintaining the building and testing infrastructure. I apologize that I can't be more helpful.

Hi folks, we will be resuming limited maintenance on this repo shortly (this will be primarily bug fixes and PR backlog reviews/merges).

@ihnorton

Following up on this in light of the recent transition from TileDB to Tile.ai.

In July, @ihnorton mentioned that limited maintenance of TileDB-R would resume shortly, primarily focusing on bug fixes and reviewing/merging the PR backlog.

It has now been about three months since that comment. As far as I can tell, this blocking issue is still unresolved, and I cannot find any related fix, PR, assignment, milestone, or other indication that it is currently being worked on.

I understand that TileDB-R itself has received some repository updates since then, so I do not mean to suggest that the repository has been completely abandoned. However, the status of bug fixing and longer-term maintenance remains unclear.

Given the recent transition from TileDB to Tile.ai, could you clarify whether the previously announced maintenance plan for TileDB-R is still active?

Specifically:

Is this issue still expected to be fixed as part of the announced limited maintenance?
Is there currently someone responsible for bug fixes and maintenance of the R client?
Does Tile.ai intend to continue maintaining existing TileDB client libraries such as TileDB-R, including compatibility and stability for existing users?
Or should downstream projects assume that TileDB-R is effectively in maintenance-only or community-supported mode going forward?

This is not merely a feature request for us. The dense [<- bug prevents TileDBArray from serving as a reliable backend for block processing in DelayedTensor, particularly for 3D+ arrays, which was one of our main reasons for adopting TileDB.

We therefore need to decide whether it is reasonable to continue investing in TileDB as a storage backend, or whether we should move to an alternative approach.

A clear statement on the current maintenance policy and the expected status of this issue would be greatly appreciated.

@kokitsuyuzaki

@kokitsuyuzaki @cgiachalis I appreciate that all of your questions have still not been answered, but in the meantime, your reviews are welcome at #896

@jdblischak

@jdblischak Thank you for the fix. I reviewed the diff and it looks good — all the cases that were blocking my use case (ncol=1 silent no-op, ncol=3 misparse, 2D-only subarray, 1D) are addressed, and the test coverage is thorough.

@jdblischak

@jdblischak One request regarding timing: Bioconductor 3.24 releases on November 25th, with a freeze on November 4th. The Bioconductor package TileDBArray imports tiledb from CRAN, so once a new tiledb version is on CRAN, the fix propagates automatically — no changes needed in TileDBArray or downstream packages like my DelayedTensor.

If this could be merged and pushed to CRAN before November 4th, downstream packages can drop their workarounds in this release cycle. Otherwise it carries over to Bioc 3.25 (spring 2027).

I understand the timeline is tight, but wanted to flag it in case it helps with prioritization.

Fix dense `[<-` writes and support `[i, j, k]` and `selected_ranges()` (

Navigation Menu

Repository navigation

Dense `[<-` write fails for 3D arrays ("Subarray should have num_dims * 2 values") #877

Minimal reproducible example

Context

Session info

Minimal example:

Session Information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	## case of dense array with subarray writes needs to set the subarray
	if (!sparse && !is.null(i) && !is.null(j) && length(allnames) == 1) {
	if (!is.vector(i) \|\| !is.vector(j)) message("'i' and 'j' should be simple vectors.")
	subarr <- as.integer(c(range(i), range(j)))
	qryptr <- libtiledb_query_set_subarray(qryptr, subarr)
	}

Dense [<- write fails for 3D arrays ("Subarray should have num_dims * 2 values") #877

Description

Minimal reproducible example

Context

Session info

Activity

kokitsuyuzaki commented on Apr 5, 2026

Minimal example:

Session Information

kokitsuyuzaki commented on Apr 5, 2026

cgiachalis commented on Apr 5, 2026

kokitsuyuzaki commented on Apr 27, 2026

kokitsuyuzaki commented on Jun 3, 2026

cgiachalis commented on Jun 3, 2026

kokitsuyuzaki commented on Jun 27, 2026

kokitsuyuzaki commented on Jun 27, 2026

jdblischak commented on Jul 1, 2026

ihnorton commented on Jul 1, 2026

kokitsuyuzaki commented on Oct 4, 2026

jdblischak commented on Oct 22, 2026

kokitsuyuzaki commented on Oct 26, 2026

kokitsuyuzaki commented on Oct 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Dense `[<-` write fails for 3D arrays ("Subarray should have num_dims * 2 values") #877