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 &lt;<a href=3D"mailto:[email protected]=
om">[email protected]</a>&gt; 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>
&gt; I&#39;m trying to understand implications of OGRLayer::WriteArrowBatch=
():<br>
&gt;<br>
&gt;&gt; This method and CreateFeature() are mutually exclusive in the same=
 session.<br>
&gt; The context is binding code where the user could potentially call<br>
&gt; either of these methods at any point during the session.<br>
&gt;<br>
&gt; Does &quot;session&quot; refer to the layer or dataset instance, or th=
e GDAL<br>
&gt; session itself?<br>
Dataset and layer instances<br>
&gt;<br>
&gt; In tests with GPKG, using WriteArrowBatch() followed by<br>
&gt; CreateFeature() worked and didn&#39;t cause any obvious problems.<br>
yes, because for that driver (actually all drivers except <br>
Parquet&amp;Arrow), WriteArrowBatch() results in CreateFeature() behind the=
 <br>
hood. But you&#39;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() &amp; 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>
&gt;=C2=A0 =C2=A0Should<br>
&gt; binding code guard against this in general?<br>
I&#39;d say up to you. The SWIG bindings don&#39;t for example.<br>
&gt;<br>
&gt; Similarly, CreateFieldFromArrowSchema() and CreateField() are mutually=
<br>
&gt; exclusive in the same session. Is there any issue with using<br>
&gt; 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&#39;t say reconciling them would be impossible, but clearly an <br>
implementation complication as I didn&#39;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==--