SQLcl: MCP Server & SQL Prompt

Hi Team,

First of all, Sorry for posting several issues back-to-back — I have a limited window without pressing tasks and I’m using it to document and improve areas where the product can better support real project workflows ( like mine :) ) .

With that said, I would like to report an issue where the **project stage** command always regenerates ORDS changesets, even when there are no actual changes in ORDS metadata.

This causes noisy diffs, and unnecessary merge conflicts

Below is a minimal reproducible test case:

1. Setup

connect -name vm_sys

drop user foo cascade;

create user foo identified by oracle;
grant connect, resource to foo;

BEGIN
  ORDS_ADMIN.ENABLE_SCHEMA(
      p_enabled             => TRUE,
      p_schema              => 'FOO',
      p_url_mapping_type    => 'BASE_PATH',
      p_url_mapping_pattern => 'foo',
      p_auto_rest_auth      => FALSE);

  ORDS_ADMIN.DEFINE_MODULE(
      p_schema         => 'FOO',
      p_module_name    => 'acm',
      p_base_path      => '/acm/',
      p_items_per_page => 1000,
      p_status         => 'PUBLISHED',
      p_comments       => NULL);

  ORDS_ADMIN.DEFINE_TEMPLATE(
      p_schema         => 'FOO',
      p_module_name    => 'acm',
      p_pattern        => 'ac_schedule',
      p_priority       => 0,
      p_etag_type      => 'HASH',
      p_etag_query     => NULL,
      p_comments       => NULL);

  ORDS_ADMIN.DEFINE_HANDLER(
      p_schema         => 'FOO',
      p_module_name    => 'acm',
      p_pattern        => 'ac_schedule',
      p_method         => 'GET',
      p_source_type    => 'json/collection',
      p_items_per_page => 10000,
      p_mimes_allowed  => NULL,
      p_comments       => NULL,
      p_source         =>
' select * from user_objects t');

END;
/
project init -name foobar -directory foobar2 -schemas foo
cd foobar2
!git init -b main

2. Adjust Filters (enable only ORDS export)

Edit:

foobar2/.dbtools/filters/project.filters

Set:

export_type in ('ORDS_SCHEMA'),

3. Export ORDS

connect foo/oracle

project export

!cat src/database/foo/ords/ords.sql

!git add .
!git commit -m "ords"

Result: Correct — ords.sql is created as expected.

Test 1 — Create and Stage Feature 1

!git checkout -b feature1
project stage
!cat dist/releases/ords/foo/ords.sql

Issue:
dist/releases/ords/foo/ords.sql is regenerated even though there are no changes in ORDS between main and feature1.

Test 2 — Branch Changes (Still No ORDS Changes)

!git add .
!git commit -m "done feature 1"

!git checkout main
!git merge feature1

!git checkout -b feature2
project stage

!git diff -- dist/releases/ords/foo/ords.sql

Issue:
The ORDS changeset is regenerated again, producing a different changeset ID even though ORDS metadata has not changed.

Output of git diff above:

diff --git a/dist/releases/ords/foo/ords.sql b/dist/releases/ords/foo/ords.sql
index b89dc6f..387f09f 100644
--- a/dist/releases/ords/foo/ords.sql
+++ b/dist/releases/ords/foo/ords.sql
@@ -1,5 +1,5 @@
 -- liquibase formatted sql
--- changeset FOO:1763742920039 stripComments:false  logicalFilePath:ords/foo/ords.sql
+-- changeset FOO:1763743293701 stripComments:false  logicalFilePath:ords/foo/ords.sql
 -- sqlcl_snapshot {"hash":"f9672576d6c7ab2a6c6ea85fc404344687024cd6","type":"ORDS_SCHEMA","name":"ords","schemaName":"FOO","sxml":""}
 --

The only thing that changes is the autogenerated changeset ID.

Impact

• Creates constant, unnecessary merge conflicts
• Makes it difficult to review real ORDS changes
• Pollutes Git history
• Happens even when ORDS export is disabled (filters turned off)

This makes working with ORDS changes inside SQLcl Project very noisy and unreliable.

Expected Behavior

• project stage should not regenerate ORDS changesets when metadata is unchanged.
  ORDS should behave the same way as other object types (tables, packages, synonyms, etc.).
• If regeneration is unavoidable, then the generated changeset must be stable.

Proposed Solution

If SQLcl must regenerate ORDS changesets every time, please consider generating them using:

• a static changeset ID, and
• runOnChange:true

Example:

-- changeset FOO:FOO_ORDS stripComments:false logicalFilePath:ords/foo/ords.sql runOnChange:true

This way:

• Git will detect no meaningful change in file contents
• Merge conflicts will disappear
• Staged artifacts will be consistent and predictable

Ideally, ORDS changesets should be produced only when metadata actually changes, but the above solution would already make the workflow much more manageable.

Thank you,
Alex