Re: M3 feature preview

Andrus Adamchik <[email protected]> Mon, 6 Jul 2026 17:11:05 -0400
Newsgroups gmane.comp.java.cayenne.devel
Message-ID <[email protected]>
The overall impact outside of the narrow JDBC benchmark will likely be =
less impressive. But I suspect it may also have a noticeable positive =
effect on DB server load. Please share how it looks in real life :)=20

Andrus


> On Jul 6, 2026, at 5:04=E2=80=AFPM, John Huss <[email protected]> =
wrote:
>=20
> 2x faster select queries is amazing! =F0=9F=94=A5
>=20
> I'm testing it right away! Thank you!
>=20
> On Mon, Jul 6, 2026 at 3:29=E2=80=AFPM Michael Gentry =
<[email protected]> wrote:
>=20
>> But... The Screaming Logs is so punk.
>>=20
>> On Mon, Jul 6, 2026 at 9:37=E2=80=AFAM Andrus Adamchik =
<[email protected]>
>> wrote:
>>=20
>>> Hi,
>>>=20
>>> I wanted to highlight a few things in the upcoming M3. They are =
already
>> on
>>> master, so maybe some brave souls can take it for a spin and give us
>>> feedback :)
>>>=20
>>> 1. Cayenne no longer wraps selecting queries (or at least those it =
can
>>> reliably identify as selecting) into transactions.
>>>=20
>>> 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 =
savings
>> in
>>> the JDBC layer with faster queries are about 2x! (as each useless
>> "commit"
>>> is a separate command sent to DB that needs to be processed). But =
this
>>> means that for the first time Cayenne operates with Connection
>>> "autoCommit=3Dtrue". So I'd appreciate feedback if this causes any
>> weirdness
>>> with your DataSources.
>>>=20
>>>=20
>>> 2. SQL logging changes. There are multiple changes. Some address
>>> operational concerns (saving hundreds of GB of storage space; =
single-line
>>> logs are easier to parse), others are "quality of life":
>>>=20
>>> * 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 =
counters,
>>> 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 =
than
>> one
>>> SQL statement)
>>>=20
>>> INFO cayenne-sql tx started
>>> INFO cayenne-sql INSERT INTO BINARY_PK_TEST1(BIN_ID, NAME) VALUES(?, =
?) |
>>>=20
>> =
bind:[BIN_ID:FBBC4034ED8F0214B2C559CF1029C1868A66F0D59208A36C9365126C248C.=
..,NAME:'master1']
>>> updated:1 time_ms:0
>>> INFO cayenne-sql tx committed
>>>=20
>>> * Mnemonic table aliases. No more meaningless t0, t1, t2:
>>>=20
>>> 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.GALLERY_ID | selected:1 time_ms:0
>>>=20
>>> * No alias for single-table queries
>>>=20
>>> INFO cayenne-sql - SELECT ESTIMATED_PRICE, PAINTING_DESCRIPTION,
>>> PAINTING_TITLE, ARTIST_ID, GALLERY_ID, PAINTING_ID FROM PAINTING |
>>> selected:2 time_ms:0
>>>=20
>>>=20
>>> (I am also thinking of lowercasing the SQL so that logs don't look =
like
>>> they are screaming at you :))
>>>=20
>>> Andrus
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20