This is an automated email from the ASF dual-hosted git repository. asf-gitbox-commits pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cayenne.git
commit b2319d53113afe2f49b202afcf3501874315d884 Author: Andrus Adamchik <[email protected]> AuthorDate: Sat Jul 18 16:17:41 2026 -0400 CAY-2978 AI skill: "cayenne-model-naming" include DbRelationship in scope --- ai-plugin/references/model-naming-conventions.md | 35 ++++++++++++++-------- ai-plugin/references/model-naming-rename-safety.md | 6 ++-- ai-plugin/skills/cayenne-model-naming/SKILL.md | 17 ++++++++--- 3 files changed, 39 insertions(+), 19 deletions(-) diff --git a/ai-plugin/references/model-naming-conventions.md b/ai-plugin/references/model-naming-conventions.md index 566252c6d..d867f3104 100644 --- a/ai-plugin/references/model-naming-conventions.md +++ b/ai-plugin/references/model-naming-conventions.md @@ -159,16 +159,25 @@ guessing. - **ObjRelationship, to-many** — plural camelCase. - **DbRelationship `name`** — mirror the paired ObjRelationship name (see below). -## DbRelationship names - -A DbRelationship name is **arbitrary** — there is no DB metadata behind it (unlike a DbEntity/ -DbAttribute, which mirror a real table/column). The working convention is that a DbRelationship's -name matches the ObjRelationship built on it, **per direction**. So when you rename a to-one -ObjRelationship to `homeTeam`, rename its backing single-hop DbRelationship to `homeTeam` as well, -and the reverse-direction pair (`homeGames`) likewise. - -Flattened (many-to-many) ObjRelationships traverse more than one DbRelationship -(`db-relationship-path="artistGroupArray.toArtist"`), so there is no 1:1 name to mirror — just keep -each individual DbRelationship name sane on its own and fix any that are numbered collisions. - -See `model-naming-rename-safety.md` for exactly what to update when you rename any of these. +## DbRelationship names — the first-class unit of relationship cleanup + +A DbRelationship `name` is **arbitrary** (not derived from a real table/column like a DbEntity/ +DbAttribute), but it is **not** exempt from cleanup — treat it as the first-class citizen here, since +every FK produces a DbRelationship whether or not an ObjRelationship was generated on it. Reverse +engineering names it with the **same generator** as ObjRelationships (`relationshipName()`: to-one = +FK column minus a trailing `_ID`/`ID`, else target entity name; to-many = English plural of the +target entity, all `underscoredToJava`-cased), so it inherits the same gaps — run-together names, +numbered collisions (`toArtist` / `toArtist1`), a leaked common prefix. Apply §1–§5 to DbRelationship +names directly, deriving the fix from the DbRelationship's own DB metadata (its FK column for to-one, +its target DbEntity pluralized for to-many). + +**Sync the ObjRelationship when one exists.** An ObjRelationship built on a DbRelationship is linked +by its `db-relationship-path` naming that DbRelationship. Keep the two names matched **per direction**: +rename both together (`homeTeam` ↔ `homeTeam`, `homeGames` ↔ `homeGames`); if one is already good, +both are. A DbRelationship with **no** ObjRelationship — an ungenerated reverse direction, a FK where +`Create ObjRelationships` was unchecked, or a hop inside a flattened many-to-many +(`db-relationship-path="artistGroupArray.toArtist"`) — is cleaned exactly the same way; there's just +no ObjRelationship to sync. + +Its name stays unique within its source DbEntity. See `model-naming-rename-safety.md` for what to +update on any rename. diff --git a/ai-plugin/references/model-naming-rename-safety.md b/ai-plugin/references/model-naming-rename-safety.md index 3d84d1e45..d82cf4111 100644 --- a/ai-plugin/references/model-naming-rename-safety.md +++ b/ai-plugin/references/model-naming-rename-safety.md @@ -79,8 +79,10 @@ name. Uniqueness is within the owning ObjEntity. | `db-relationship-path` **segments** | Every `<obj-relationship>` whose `db-relationship-path` contains `a` — **including inside dotted flattened chains**. E.g. path `artistGroupArray.toArtist`, renaming `toArtist` → `b` gives `artistGroupArray.b`. These references can live on entities other than the DbRelationship's source. | No Java impact — DbRelationships are a DB-layer concept. Uniqueness is within the source DbEntity -(attrs + rels). Keep the name mirrored with its paired ObjRelationship per direction (see -`model-naming-conventions.md`). +(attrs + rels). If the DbRelationship backs an ObjRelationship, keep the name mirrored with it per +direction; if it is **standalone** (no ObjRelationship built on it — see `model-naming-conventions.md`), +there is nothing to mirror, but the `db-relationship-path` update above still applies: a standalone +DbRelationship can appear as a segment in another entity's flattened path. ## Paired renames diff --git a/ai-plugin/skills/cayenne-model-naming/SKILL.md b/ai-plugin/skills/cayenne-model-naming/SKILL.md index 1a4cabfa2..998d62957 100644 --- a/ai-plugin/skills/cayenne-model-naming/SKILL.md +++ b/ai-plugin/skills/cayenne-model-naming/SKILL.md @@ -1,6 +1,6 @@ --- name: cayenne-model-naming -description: "Use this skill to clean up Object-layer names in a Cayenne DataMap — ObjEntity, ObjAttribute, and ObjRelationship names (plus the paired DbRelationship names, which are arbitrary and conventionally mirror the ObjRelationship) — so they read as descriptive, consistent Java. Trigger on phrases like 'clean up the model names', 'fix the entity names', 'these names look ugly', 'make the names descriptive', 'normalize the ObjEntity/attribute/relationship names', 'why is this rela [...] +description: "Use this skill to clean up Object-layer names in a Cayenne DataMap — ObjEntity, ObjAttribute, and ObjRelationship names, plus DbRelationship names (the first-class unit of relationship cleanup — every FK has one whether or not an ObjRelationship was generated; the ObjRelationship name is synced to it when one exists) — so they read as descriptive, consistent Java. Trigger on phrases like 'clean up the model names', 'fix the entity names', 'these names look ugly', 'make the [...] --- <!-- @@ -92,8 +92,14 @@ correct — leave them.** Flag only the cases the deterministic generator can't abbreviations applied consistently, plural-table-to-singular-entity. Conservative by default; when unsure, leave the baseline name and ask. -Remember DbRelationship names are arbitrary and conventionally mirror the paired ObjRelationship -name — when you rename a relationship, plan the mirrored DbRelationship rename too. +Relationship cleanup is anchored on the **DbRelationship** — it's the first-class citizen, since +every FK has one whether or not an ObjRelationship was generated on top. The rules above (run-together, +numbered collisions, prefix leak) apply to DbRelationship names directly, derived from their own DB +metadata (FK column for to-one, pluralized target DbEntity for to-many). When an ObjRelationship *is* +built on a DbRelationship, keep the two names **in sync** — rename both together, per direction. +DbRelationships with no ObjRelationship (an ungenerated reverse direction, a skipped FK, a hop inside +a flattened many-to-many) are cleaned the same way — don't skip them. Any rename must update every +`db-relationship-path` segment that names it (see Step 4). ## Step 3 — Present the rename plan @@ -117,7 +123,8 @@ Edit the `*.map.xml`. For **every** rename, walk the matching checklist in - ObjRelationship → prefetch/expression/EJBQL paths (its `db-relationship-path` is unaffected). - ObjAttribute → qualifier/ordering/EJBQL paths (its `db-attribute-path` is unaffected). - DbRelationship → every `db-relationship-path` segment that names it, including inside dotted - flattened chains. + flattened chains. This holds whether or not the DbRelationship backs an ObjRelationship — a + standalone DbRelationship can still be named as a segment in another entity's flattened path. Keep every name unique within its scope, and preserve the file's existing formatting and element order. @@ -143,6 +150,8 @@ order. bare rename orphans the old class and dangles relationship `source`/`target` and query `root-name`. - **Don't rename a DbRelationship without fixing every `db-relationship-path` segment**, including flattened chains on other entities. +- **Don't skip a DbRelationship just because it has no ObjRelationship.** Standalone DbRelationships + are in scope — clean them on their own merits from their DB metadata, not by mirroring. - **Don't repoint `db-attribute-path` / `db-relationship-path` targets.** You rename the element; you never change what a path points to. - **Don't run cgen yourself.** Hand off to `cayenne-cgen`.
