Re: OGRLayer::WriteArrowBatch() and CreateFeature() mutually exclusive in the same session
Chris Toney via gdal-dev <[email protected]> Mon, 11 May 2026 15:39:56 -0600
| Newsgroups | gmane.comp.gis.gdal.devel |
|---|---|
| Message-ID | <CALRbqOR17XOv2LSfdfYOOpp+YFo5D+Ui9+m53QXeUmm89WeAHQ@mail.gmail.com> |
--===============2188302011836317678== Content-Type: multipart/alternative; boundary="00000000000016d12c06519197e6" --00000000000016d12c06519197e6 Content-Type: text/plain; charset="UTF-8" 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. > > --00000000000016d12c06519197e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Thanks Even, that helps a lot.<div dir=3D"auto"><br>= </div><div dir=3D"auto">Chris=C2=A0</div><br><br><div class=3D"gmail_quote = gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 11= , 2026, 2:50 AM Even Rouault <<a href=3D"mailto:[email protected]= om">[email protected]</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex">Chris,<br> > I'm trying to understand implications of OGRLayer::WriteArrowBatch= ():<br> ><br> >> This method and CreateFeature() are mutually exclusive in the same= session.<br> > The context is binding code where the user could potentially call<br> > either of these methods at any point during the session.<br> ><br> > Does "session" refer to the layer or dataset instance, or th= e GDAL<br> > session itself?<br> Dataset and layer instances<br> ><br> > In tests with GPKG, using WriteArrowBatch() followed by<br> > CreateFeature() worked and didn't cause any obvious problems.<br> yes, because for that driver (actually all drivers except <br> Parquet&Arrow), WriteArrowBatch() results in CreateFeature() behind the= <br> hood. But you'd likely hit issues on Parquet or Arrow datasets, for <br= > which implementation limitations lead to the general restriction.=C2=A0 And= <br> as we have nothing in the test suite that checks that mixing <br> WriteArrowBatch() & CreateFeature() works even for code where it is OK = <br> currently, you could be exposed to potential regressions if the <br> implementation changed in the future.<br> >=C2=A0 =C2=A0Should<br> > binding code guard against this in general?<br> I'd say up to you. The SWIG bindings don't for example.<br> ><br> > Similarly, CreateFieldFromArrowSchema() and CreateField() are mutually= <br> > exclusive in the same session. Is there any issue with using<br> > CreateField() and WriteArrowBatch() in the same session?<br> <br> Same as above w.r.t Arrow/Parquet driver. The feature writing logic <br> between the Arrow and per-feature strategies takes different code paths. <b= r> I don't say reconciling them would be impossible, but clearly an <br> implementation complication as I didn't see the point in supporting <br= > mixed workflows.<br> <br> Even<br> <br> <br> -- <br> <a href=3D"http://www.spatialys.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://www.spatialys.com</a><br> My software is free, but my time generally not.<br> <br> </blockquote></div></div></div> --00000000000016d12c06519197e6-- --===============2188302011836317678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev --===============2188302011836317678==--