Thanks Even, that helps a lot. Chris
On Mon, May 11, 2026, 2:50 AM Even Rouault <[email protected]> wrote: > Chris, > > I'm trying to understand implications of OGRLayer::WriteArrowBatch(): > > > >> This method and CreateFeature() are mutually exclusive in the same > session. > > The context is binding code where the user could potentially call > > either of these methods at any point during the session. > > > > Does "session" refer to the layer or dataset instance, or the GDAL > > session itself? > Dataset and layer instances > > > > In tests with GPKG, using WriteArrowBatch() followed by > > CreateFeature() worked and didn't cause any obvious problems. > yes, because for that driver (actually all drivers except > Parquet&Arrow), WriteArrowBatch() results in CreateFeature() behind the > hood. But you'd likely hit issues on Parquet or Arrow datasets, for > which implementation limitations lead to the general restriction. And > as we have nothing in the test suite that checks that mixing > WriteArrowBatch() & CreateFeature() works even for code where it is OK > currently, you could be exposed to potential regressions if the > implementation changed in the future. > > Should > > binding code guard against this in general? > I'd say up to you. The SWIG bindings don't for example. > > > > Similarly, CreateFieldFromArrowSchema() and CreateField() are mutually > > exclusive in the same session. Is there any issue with using > > CreateField() and WriteArrowBatch() in the same session? > > Same as above w.r.t Arrow/Parquet driver. The feature writing logic > between the Arrow and per-feature strategies takes different code paths. > I don't say reconciling them would be impossible, but clearly an > implementation complication as I didn't see the point in supporting > mixed workflows. > > Even > > > -- > http://www.spatialys.com > My software is free, but my time generally not. > >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
