Refactor naming policy of database schema elements
--------------------------------------------------
Key: OPENJPA-1304
URL: https://issues.apache.org/jira/browse/OPENJPA-1304
Project: OpenJPA
Issue Type: Improvement
Components: jdbc, jpa, kernel, query, sql
Affects Versions: 2.0.0-M3, 2.0.0-M4, 2.0.0
Reporter: Pinaki Poddar
Assignee: Pinaki Poddar
Fix For: 2.0.0
The issue of naming database elements
(Table/Column/Schema/Sequence/Constraints) is getting trickier with several
aspects
a) The logic/protocol of naming of database elements is somewhat well-spread
at different parts
b) few assumptions are implicit (like full name of a table is a concatenation
of schema.table -- but MySQL, for example, will not like that)
c) other 'container' things often cache these elements by their names but
these names may get shortened/modified because of database length
restrictions/keyword clash
d) database variations impose few other twists (such as case-sensitivity)
-- all these make naming a complex issue. One can see when methods like
MappingDefaults.correctName() appear -- as if we know we have done mistakes
elsewhere :)
e) the proverbial straw on the camel's back is the new JPA 2.0 requirement of
these names be optionally quoted/delimited with default/platform specific quote
characters.
The question is should we attempt refactoring name-related operations into a
DatabaseElementNamingPolicy?
Is it too risky?
If we do how the policy works with DBDictionary?
How can we ensure backward compatibility?
How can we leverage it by adding new features that follow some rules to map
name persistent Java element names to database element names saving the user to
specify column names everywhere?
Comments/Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.