[
https://issues.apache.org/jira/browse/CAY-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik closed CAY-2978.
--------------------------------
Resolution: Fixed
> AI skill: "cayenne-model-naming"
> --------------------------------
>
> Key: CAY-2978
> URL: https://issues.apache.org/jira/browse/CAY-2978
> Project: Cayenne
> Issue Type: Task
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Priority: Major
> Fix For: 5.0-M3
>
>
> Let's create a new AI skill under "ai-plugin" called "cayenne-model-naming".
> Its goal is to cleanup Obj layer model names (ObjEntity, ObjAttribute,
> ObjRelationship) so that they look descriptove and consistent in Java. One
> exception - the same skill applies to DbRelationships (DbRelationship name is
> aribitrary and does not correspond to any DB metadata; also Obj and Db
> relationship names usually match each other).
> Use cases:
> 1. right after "cayenne-db-import" skill was invoked (focus on the new model
> additions)
> 2. on an explicit user request
> Distiguish between two types of requests - "clean the entire model" (rare) vs
> "clean just the changed elements" (should implicitly be the case after
> "cayenne-db-import" is called). Since "cayenne-db-import" doesn't return
> which entitioes have changed (or were added), use git diff to detect the
> scope (and if the project is not under Git version control, fall back to
> "entire model").
> Note that CayenneModeler automatically generates very decent names in most
> cases. So don't rewrite everything. Check the currently used algorithms and
> only improve the things they can't do. Current principles:
> 1. Obj names should as very close to Db names as possible
> 2. Follow Java class and identifier conventions
> 3. Rewrite Db snake case names to camel case
> 4. Use simple heuristics to name relationships between two entities based on
> entity name and to-one/to-many semantics
>
> Here are some cases when the existing deterministic algorithm falls short and
> we need AI:
> 1. Obscure naming in the underlying database. E.g. no snake case separators
> ("gametype" table should produce "GameType", not "Gametype").
> 2. More than one relationship between two tables (resulting in "table" and
> "table1" relationhip names). Preferred naming should be based on FK names for
> to-one and something logically opposite for to-many
> 3. Relationships using common table prefixes (e.g. when every table starts
> with "os_", every relationship will too).
> 4. There may be more cases that we didn't identify explicitly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
