[hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

Another thing to consider here...  In regards to physical naming, one of
the aspects we need to consider is to possibly shorten names based on the
maximum identifier length per Dialect[1].  PhysicalNamingStrategy is the
most natural place to put this.  However, that means when a user supplies
a PhysicalNamingStrategy the onus is on their impl to make sure this length
constraint is accomplished.

What do y'all think of that?

I don't think it is necessarily a deal-breaker.  Worst case, it would be
super easy for them to simply delegate to some standard (dumb) length
handling.  Or they could implement smarter (contextual) shortening (NUMBER
becomes NM or NO rather than NUM, e.g)


[1] - I vaguely recall seeing that certain databases allow different length
constraints for different types of identifiers (table name, versus column
name, versus constrain name, ...).  Can anyone confirm that?

On Fri, Jan 16, 2015 at 4:27 PM, Steve Ebersole <steve at hibernate.org> wrote:

> In my opinion, this blend of implicit naming and explicit naming is just
> asking for problems.  But to answer your specific question, yes.. altering
> the naming stratagies used could conceivably mess up cross referencing in
> cases like this.
> On Jan 16, 2015 12:09 PM, "Emmanuel Bernard" <emmanuel at hibernate.org>
> wrote:
>
>>
>> On 16 Jan 2015, at 18:37, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>>
>>>> I have one question, regarding logical name. The name that a given user
>>>> needs to use inside say @Column( …, table=“SomeEntity1”) is the name that
>>>> comes out of the implicit naming contract (assuming the original table was
>>>> implicit). Is that correct?
>>>>
>>>
>>> This is true.  But remember that this is mainly intended to signify a
>>> secondary table, whose name cannot be implicit.  Also, I think that mixing
>>> implicit naming and explicit naming and expecting that to work is not
>>> necessarily a valid expectation.
>>>
>>
>> I just wanted to clarify here a bit.  As far as I know, the only time
>> that this could be a problem is when we need @Column to refer to the
>> primary table and the name of the primary table is implicit.  But JPA
>> designs for that by saying that @Column is expected to refer to the primary
>> table when @Column#table is null or not specified.  What I was saying above
>> was this, imo, it is not a reasonable for this to work:
>>
>> @Entity
>> public Customer {
>>     @Column( ..., table="Customer" )
>>     ...
>> }
>>
>> I just think that makes no sense.
>>
>> Am I missing any potential uses where @Column#table would refer to
>> something that might reasonably be implicit?
>>
>>
>> No but it might be more problematic for `@JoinColumn(name=“customer_fk,
>> referencedColumnName=“id”)` where the referenced entity has `@Id String
>> id`. That family of references might be more common than secondary tables.
>>
>