Hi SQLcl team,
First, thank you for the 26.1 release.
I had been waiting for this version specifically because project export through the SQLcl MCP server finally appears to be working for me now. That was genuinely exciting, because this issue was blocking a workflow I depend on.
Before I go further, I also want to say that I have a lot of respect for what you are building with SQLcl Projects. It’s an extremely valuable direction and I rely on it heavily.
However, immediately after testing 26.1, I ran into another problem that makes the upgrade unusable in practice.
For tables with generated identity columns, the exported create table output changed significantly.
In 25.4, I was getting output like this:
create table cla_apex.fbo_tr_delivery_modes (
delivery_mode_id number generated by default on null as identity not null enable,
In 26.1, the same column is exported as:
create table cla_apex.fbo_tr_delivery_modes (
delivery_mode_id number generated by default on null as identity minvalue 1 maxvalue 9999999999999999999999999999 increment
by 1 cache 20 noorder nocycle nokeep noscale not null enable,
As a result, one export attempt produced diffs in all 300+ tables in my project. That is an immediate “no go” for version upgrade, because it creates massive noise with no real schema change.
My first thought was that perhaps this was just a DBMS_METADATA change being passed through. But after rolling back to 25.4, project export produced the previous output again. So this does appear to be a SQLcl behavior change, not just a database-side metadata difference.
My first question is very practical:
- Is there any parameter or setting in
.dbtools/project.config.json that would let me keep the old behavior in 26.1?
If there is such a setting, that would solve my immediate problem.
My second point is broader:
- SQLcl Projects is infrastructure, not just a convenience feature. Once teams rely on it for version control and deployment workflows, output compatibility becomes a stability requirement, not a nice-to-have.
- I assume this change was made for a reason, likely in response to a real customer request. That is completely fair. But from first principles, when a new export style is introduced, the default should remain backward-compatible, and the more verbose behavior should be enabled through an explicit parameter.
- Otherwise, existing users pay the cost in the form of hundreds of artificial diffs and blocked upgrades, and then have to ask in the forum whether there is some hidden switch to restore the previous output.
I’m not trying to complain for the sake of complaining. I’m pointing this out because people do depend on this tool, and output changes like this have a very real downstream impact.
Thanks in advance for any guidance.
Best,
Alex