Skip to content

Commit 17b27f7

Browse files
committed
Merge remote-tracking branch 'origin/main' into restructure-and-shord-ids
2 parents 5a6604a + 20e43eb commit 17b27f7

File tree

1 file changed

+22
-0
lines changed

1 file changed

+22
-0
lines changed

docs/v3/core/v3.0.rst

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1601,6 +1601,28 @@ a prefix will erase all the implicit group in the prefix.
16011601
Care must thus be taken when erasing an array or a group if the parent needs to
16021602
be converted into an explicit group.
16031603

1604+
Resizing
1605+
--------
1606+
1607+
In general, arrays can be resized for writable (and if necessary deletable)
1608+
stores. In the most basic case, two scenarios can be considered, shrinking along
1609+
an array dimension, or increasing its size.
1610+
1611+
When shrinking, implementations can consider to delete chunks if the store
1612+
allows this, or keep them. This should either be configurable, or be
1613+
communicated to the user appropriately.
1614+
1615+
When increasing an array along a dimension, chunks may or may not have existed
1616+
in the new area. For areas where no chunks existed previously, they implicitly
1617+
have the fill value after updating the metadata, no new chunks need to be
1618+
written in this case. Previous partial chunks will contain the fill value at the
1619+
time of writing them by default. If there was chunk data in the new area which
1620+
was not deleted when shrinking the array, this data will be shown by default.
1621+
The latter case should be signalled to the user appropriately. An implementation
1622+
can also allow the user to choose to delete previous data explicitly when
1623+
increasing the array (by writing the fill value into partial chunks and deleting
1624+
others), but this should not be the default behavior.
1625+
16041626

16051627
Comparison with Zarr v2
16061628
=======================

0 commit comments

Comments
 (0)