Re: M3 feature preview

Hello Andrus,

more of a curiosity here than an actual Cayenne consideration: I love
the idea of non performing an explicit commit for select queries, but
do you actually need the set 'autoCommit=3Dtrue', or is this just a safe
option in case there were triggers or other subtle changes on the data
that would not be saved otherwise?

Thanks,

Giulio Cesare

On Sun, Jul 12, 2026 at 10:35=E2=80=AFPM Andrus Adamchik <[email protected]=
om> wrote:
>
> The M3 change only affects selects. Previously, each select was performed=
 with autoCommit=3Dfalse, and was followed by an explicit Connection.commit=
(). Now we switched to autoCommit=3Dtrue and no explicit commit.
>
> Hope this explains the change.
>
> Andrus
>
>
>
> > On Jul 12, 2026, at 4:10=E2=80=AFAM, Jurgen Doll <[email protected]=
> wrote:
> >
> > Hi Andrus
> >
> > Wrt autoCommit I'm a bit puzzled as to why: "Cayenne no longer wraps se=
lecting queries ...." therefore ".... this means that for the first time Ca=
yenne operates with Connection 'autoCommit=3Dtrue'" ? Are selects and autoC=
ommit related in some way ?
> > I'm asking because in my understanding autoCommit is only relevant to u=
pdates and inserts which will still be wrapped as transactions won't they ?
> > Or are you saying that there isn't any default transaction wrapping at =
all any more in Cayenne, even for inserts and updates ?
> >
> > Thanks for a great library!
> > Jurgen
> >
> > On Jul 11 2026, at 9:21 pm, Andrus Adamchik <[email protected]> wrote=
:
> >> As a Cayenne user, the majority of my apps in the last 25 years were "=
autoCommit=3Dfalse" just because that's how the framework worked. So this i=
s also new to me and based on research, not production experience. So I'd v=
ery much like to get community feedback on the actual behavior and potentia=
l pitfalls.
> >>
> >> Andrus
> >>
> >>> On Jul 11, 2026, at 4:52=E2=80=AFAM, [email protected] wrote:
> >>>
> >>> Hello Andrus,
> >>>
> >>>> But this means that for the first time Cayenne operates with Connect=
ion "autoCommit=3Dtrue".
> >>>
> >>> =F0=9F=98=B1
> >>> This setting is more scary that an Halloween costume to me! =F0=9F=98=
=85
> >>> I trust your understanding of the trade-offs at play, but I have
> >>> always considered autoCommit the option used by toy projects, not
> >>> suitable for serious tasks.
> >>>
> >>> But my views may well be obsolete by now. =F0=9F=98=81
> >>>
> >>> Cheers, and =E2=80=93as always=E2=80=93 huge congratulations to all p=
eople involved in
> >>> moving the project forward.
> >>>
> >>> Giulio Cesare
> >>>
> >>> On Tue, Jul 7, 2026 at 3:17=E2=80=AFPM Andrus Adamchik <aadamchik@gma=
il.com> wrote:
> >>>>
> >>>> I am glad the new change didn't break much stuff :) Always a concern=
 with all the new ideas.
> >>>>
> >>>> BTW, as you probably noticed, we are now exposing translated queries=
 with parameters as standalone record objects instead of going straight fro=
m translator to PreparedStatement, so they can be captured, inspected, logg=
ed, etc (e.g., what the SQLLogger does).
> >>>>
> >>>> And on the broader topic of observability, we started an effort to i=
ntegrate OpenTelemetry into Bootique, and I hope this will come back to Cay=
enne as well. Would be nice to have otel spans for queries. But as your vid=
eo demonstrates, explicit instrumentation is almost irrelevant these days. =
The tools are so good... they can grab the logs, or do automated runtime in=
strumentation and show you transaction traces with next to zero effort.
> >>>>
> >>>> Andrus
> >>>>
> >>>>
> >>>>
> >>>>> On Jul 6, 2026, at 7:15=E2=80=AFPM, Hugi Thordarson <hugi@karlmenn.=
is> wrote:
> >>>>>
> >>>>> Hi Andrus,
> >>>>>
> >>>>> first =E2=80=94 that logging is a vast, vast improvement, I'm lovin=
g it!
> >>>>>
> >>>>> So happens I've been playing a lot with Cayenne's logging lately. V=
ery happy about how easy it was/is to hook into query logging and I've used=
 it to profile SQL-queries in my web application templates for years now =
=E2=80=94 keeping track of the time methods spend querying to find performa=
nce problems (profiling/aggregating by bindings rather than methods really,=
 in WO terms) and watching the SQL they executed.
> >>>>>
> >>>>> Helpful, but has always been private utility logic for myself since=
 it just prints ugly text reports and I never took the time to make it pret=
ty and usable for others.
> >>>>>
> >>>>> But that was before Claude :). So now there's this: Inline SQL logg=
ing. Probably easiest described through video =E2=80=94 https://www.youtube=
.com/watch?v=3DhoW1WusKSRo .
> >>>>>
> >>>>> =E2=80=A6works great with the new SQLLogger interface. Already port=
ed, since I'll be switching to -SNAPSHOT (in dev only for a while, to test =
the behaviour of the new transaction setup, really looking forward to putti=
ng it through it's paces).
> >>>>> Been using M2 in production since release and it works great, congr=
ats on another awesome release :).
> >>>>>
> >>>>> Cheers,
> >>>>> - hugi
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 6 Jul 2026, at 13:37, Andrus Adamchik <[email protected]> wro=
te:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I wanted to highlight a few things in the upcoming M3. They are al=
ready on master, so maybe some brave souls can take it for a spin and give =
us feedback :)
> >>>>>>
> >>>>>> 1. Cayenne no longer wraps selecting queries (or at least those it=
 can reliably identify as selecting) into transactions.
> >>>>>>
> >>>>>> I had a suspicion for years that we shouldn't be doing that. Now I=
 was able to vibecode real benchmarks on multiple databases, and time savin=
gs in the JDBC layer with faster queries are about 2x! (as each useless "co=
mmit" is a separate command sent to DB that needs to be processed). But thi=
s means that for the first time Cayenne operates with Connection "autoCommi=
t=3Dtrue". So I'd appreciate feedback if this causes any weirdness with you=
r DataSources.
> >>>>>>
> >>>>>>
> >>>>>> 2. SQL logging changes. There are multiple changes. Some address o=
perational concerns (saving hundreds of GB of storage space; single-line lo=
gs are easier to parse), others are "quality of life":
> >>>>>>
> >>>>>> * No tx for selects (mentioned above) by itself cuts down on 2 log=
 lines per query
> >>>>>> * The new logger name is short and descriptive "cayenne-sql"
> >>>>>> * ERROR log level for queries that result in exceptions
> >>>>>> * SQL query logs are single-line. Parameters, timers, result count=
ers, generated keys are placed on one line and rendered in a compact format=
. Tx wrapping is still done on separate lines (as a tx can include more tha=
n one SQL statement)
> >>>>>>
> >>>>>> INFO cayenne-sql tx started
> >>>>>> INFO cayenne-sql INSERT INTO BINARY_PK_TEST1(BIN_ID, NAME) VALUES(=
?, ?) | bind:[BIN_ID:FBBC4034ED8F0214B2C559CF1029C1868A66F0D59208A36C936512=
6C248C...,NAME:'master1'] updated:1 time_ms:0
> >>>>>> INFO cayenne-sql tx committed
> >>>>>>
> >>>>>> * Mnemonic table aliases. No more meaningless t0, t1, t2:
> >>>>>>
> >>>>>> INFO cayenne-sql SELECT p.ESTIMATED_PRICE, p.PAINTING_DESCRIPTION,=
 p.PAINTING_TITLE, p.ARTIST_ID, p.GALLERY_ID, p.PAINTING_ID, g.GALLERY_ID, =
g.GALLERY_NAME FROM PAINTING p LEFT JOIN GALLERY g ON p.GALLERY_ID =3D g.GA=
LLERY_ID | selected:1 time_ms:0
> >>>>>>
> >>>>>> * No alias for single-table queries
> >>>>>>
> >>>>>> INFO cayenne-sql - SELECT ESTIMATED_PRICE, PAINTING_DESCRIPTION, P=
AINTING_TITLE, ARTIST_ID, GALLERY_ID, PAINTING_ID FROM PAINTING | selected:=
2 time_ms:0
> >>>>>>
> >>>>>>
> >>>>>> (I am also thinking of lowercasing the SQL so that logs don't look=
 like they are screaming at you :))
> >>>>>>
> >>>>>> Andrus
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >
>