[
https://issues.apache.org/jira/browse/CAY-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-2978:
---------------------------------
Description:
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. There may be more cases that we didn't identify explicitly
was:
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").
Amend "cayenne-db-import" skill to automatically invoke "cayenne-model-naming"
after a non-empty import.
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. There may be more cases that we didn't identify explicitly
> 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. There may be more cases that we didn't identify explicitly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
