Rename catalog.modules.IsSystemModule

[mkrouwel]

Querying the catalog is very powerful for analysis. I noticed in the modules table there is a column named IsSystemModule. Considering the System Module itself is not listed as row, and considering the values, I suggest to rename this column to IsMarketPlaceModule. Maybe you want to make it an enum/string value with possible values: MarketPlace, Addon, Theme, System, Own, etc.

Mxcli version: 0.4
Mendix version: irrelevant, I use 11.6

[github-actions]

Issue Triage

Summary:
The user requests renaming the IsSystemModule column in the catalog’s modules table to IsMarketPlaceModule (possibly expanding it to an enum) to better reflect its meaning when querying the catalog for analysis.

Checklist for feature request:

• ✅ Use case – why the feature is needed / problem it solves
• ✅ Proposed syntax or behavior (rename column, optional enum values)
• ✅ Mendix version relevance (noted as irrelevant, but version 11.6 mentioned)

Feedback:
The issue contains all the required information for a feature request. Thank you for the suggestion!

---

Automated triage via OpenRouter — workflow source

[github-actions]

Enhancement Implementation Guide

Completeness Assessment

The enhancement request provides basic details but lacks critical information needed for implementation. To properly implement this change, I need clarification on:

Specific questions to ask the reporter:

1. What is the current data type of the IsSystemModule column? (Boolean, integer, etc.)
2. Should this be a pure rename, or does it involve changing the column's semantics to an enum/string with values like MarketPlace, Addon, Theme, System, Own?
3. Are there specific Mendix module properties that determine these categories? (e.g., from module metadata in the MPR)
4. Is backward compatibility required? Should we maintain the old column name alongside the new one?
5. What exact values should the enum take, and how should they map to actual module types in Mendix?

The request mentions Mendix version 11.6 and mxcli version 0.4, which is helpful context.

Overlap Check

This enhancement doesn't overlap with existing MDL syntax for modifying Mendix model elements (entities, microflows, etc.). Instead, it concerns the internal SQLite-based catalog used for querying project metadata.

Existing related functionality:

• SHOW CATALOG TABLES and SELECT ... FROM CATALOG.table for querying metadata
• The catalog already contains a modules table with module information
• REFRESH CATALOG rebuilds the metadata tables

This is purely a modification to the catalog schema, not to user-facing MDL statements.

Proposed MDL Syntax

This enhancement doesn't introduce new MDL syntax that users would write. Rather, it modifies the schema of an existing catalog table that users query against.

Current usage:

SELECT * FROM CATALOG.modules WHERE IsSystemModule = 1

Proposed usage after change:

SELECT * FROM CATALOG.modules WHERE IsMarketPlaceModule = 1

Or, if converted to an enum/string:

SELECT * FROM CATALOG.modules WHERE ModuleType = 'MarketPlace'

Note: This is not about adding CREATE/ALTER/etc. statements, but about modifying the internal catalog table structure.

Implementation Roadmap

Step 1: Investigation

• Examine mdl/catalog/tables.go for the modules table definition
• Check mdl/catalog/builder_modules.go for how the table is populated
• Determine current column name, type, and what it actually represents
• Look at how module information is extracted from MPR/BSON to understand available properties

Step 2: Modify Catalog Schema

Files to modify:

• mdl/catalog/tables.go - Update modules table column definition
• mdl/catalog/builder_modules.go - Update column population logic

Changes:

• If renaming only: Change column definition from IsSystemModule to IsMarketPlaceModule
• If converting to enum: Change column type to TEXT/STRING and update population logic to set appropriate string values

Step 3: Update Population Logic

• Modify the code that inserts/updates rows in the modules table
• Determine correct values based on module properties from MPR (likely checking for marketplace-specific attributes)
• For boolean approach: Set to 1 for marketplace modules, 0 otherwise
• For enum approach: Set to 'MarketPlace', 'Addon', 'Theme', 'System', 'Own', etc. based on module characteristics

Step 4: Update References

• Search codebase for IsSystemModule references and update appropriately
• Check test files, documentation, and any other references
• Consider maintaining backward compatibility if needed (e.g., keeping old column as deprecated)

Step 5: Testing & Validation

• Verify SHOW CATALOG TABLES shows updated table structure
• Test querying the new column with various module types
• Ensure REFRESH CATALOG correctly populates the new column
• Validate that existing catalog functionality remains intact

BSON Investigation

This change primarily affects the catalog (SQLite-based), not direct BSON structures. However, understanding how module data flows from MPR to catalog is important:

Investigation steps:

1. Examine how the modules table is currently populated in builder_modules.go
2. Check what module properties are available from the parsed MPR/BSON that could indicate module type
3. Look at existing module metadata extraction to see what flags/properties distinguish marketplace modules
4. Verify what the current IsSystemModule column actually represents by:
   • Creating test projects with different module types
   • Checking the column values in the catalog
   • Comparing against known module properties in Studio Pro

Key files to check:

• mdl/catalog/builder_modules.go - How module data is inserted into catalog
• MPR parsing code (in sdk/mpr/) to understand available module properties
• Reflection data in reference/mendixmodellib/reflection-data/ for module definitions

Testing Strategy

Doctype Test Script

Not applicable (this isn't a new MDL statement type), but add verification to existing catalog tests.

mx check Validations

Not applicable (this doesn't produce CE errors in Studio Pro as it's a CLI/catalog feature).

Integration Tests

1. Create test projects with various module types (marketplace, system, regular, etc.)
2. Run REFRESH CATALOG FULL to ensure complete metadata
3. Verify:
   • SHOW CATALOG TABLES shows the updated modules table structure
   • SELECT IsMarketPlaceModule FROM CATALOG.modules returns expected values
   • The column correctly identifies marketplace modules vs others
   • If using enum approach: SELECT DISTINCT ModuleType FROM CATALOG.modules shows expected values
4. Test round-trip: Ensure catalog refreshes correctly maintain the new column data
5. Verify existing catalog queries still work (no regression)

Gotchas & Risks

Backward Compatibility

• Risk: Renaming breaks existing user queries that reference IsSystemModule
• Mitigation:
  • Keep old column as deprecated (with same values) for one release cycle
  • Or provide clear migration notes in release documentation
  • Consider adding a view or computed column if feasible

Correct Classification

• Risk: Incorrectly identifying what constitutes a "MarketPlace" module
• Mitigation:
  • Research Mendix documentation on module types
  • Examine actual MPR files from known marketplace vs system vs regular modules
  • Look for definitive properties in module metadata (not just naming conventions)

Data Type Change

• Risk: Changing from boolean to string requires data migration
• Mitigation:
  • If changing type, implement proper migration in catalog initialization
  • Handle both old and new formats during transition period
  • Consider keeping boolean column and adding string column simultaneously initially

Performance

• Risk: String columns use more storage than boolean
• Mitigation:
  • Impact is minimal for typical module counts (<1000 modules)
  • Consider using ENUM-like storage if supported by SQLite (CHECK constraints)
  • Monitor catalog size in performance tests

Critical Verification

Before implementing, create test projects in Studio Pro with known module types to verify:

• What the current IsSystemModule column actually contains
• What properties definitively identify marketplace modules
• Whether the System Module appears in the modules table (as noted in the request)

---

Automated guide via OpenRouter — workflow source

[ako]

Good catch @mkrouwel. You're right — IsSystemModule is misleading. The column is set from Module.FromAppStore (which is true for Marketplace modules), not from whether it's a System module.

Current state

• The catalog column IsSystemModule is an INTEGER (0/1) set from Module.FromAppStore
• SHOW MODULES already shows a Source column with "Marketplace v4.3.2" — much more descriptive
• The Module struct also has IsReusableComponent which isn't exposed in the catalog

Proposed change

Rename IsSystemModule to Source as a TEXT column with values:

Value	Meaning
"" (empty)	User-created module
"Marketplace v4.3.2"	Marketplace module with version
"Marketplace"	Marketplace module (no version)

This matches what SHOW MODULES already displays and is more useful for queries like:

SELECT name FROM catalog.modules WHERE source = '';        -- user modules only
SELECT name FROM catalog.modules WHERE source LIKE 'Marketplace%';  -- marketplace only

The integer IsSystemModule would be kept as a deprecated alias for backward compatibility (computed from Source != '').

We'll include this in the next release.

[ako]

Implemented in 2a77470.

Renamed IsSystemModule (INTEGER 0/1) to Source (TEXT) with descriptive values:

Value	Meaning
"" (empty)	User-created module
"Marketplace v4.3.2"	Marketplace module with version
"Marketplace"	Marketplace module (no version)

Example queries:

-- User modules only
SELECT name FROM catalog.modules WHERE source = '';

-- Marketplace modules
SELECT name FROM catalog.modules WHERE source LIKE 'Marketplace%';

Updated all internal references (linter queries, SHOW STRUCTURE filtering, tests).