Gail Badner·11:18 AM
@SteveEbersole, quick question about HHH-10713 - @JoinColumn and @Column mapping to String PK require length to be defined New
HHH-10713 - @JoinColumn and @Column mapping to String PK require length to be defined New : @JoinColumn and @Column mapping to String PK require length to be defined hibernate.atlassian.net
Type: Bug
Priority: Major
Status: Open
is this expected? iow, should length/precision/etc be taken from columns mapped with insertable=false, updatable=false?
I suspect this happened due to the order in which attributes are mapped (basic attributes before associations)
but I haven't checked it
Steve Ebersole·11:28 AM
@GailBadner you mean as opposed to another column?
...
Gail Badner·11:35 AM
@SteveEbersole wimi, if there are 2 columns mapped for the same column and one of them is mapped with insertable=false, updatable=false, should length/precision/etc be taken from other column (with insertable=true, updatable=true)?
Steve Ebersole·11:35 AM
sure, i dont think there is anything inherently wrong with that
Gail Badner·11:37 AM
@SteveEbersole was your response to my question?
Steve Ebersole·11:37 AM
yep
Gail Badner·11:37 AM
ok, thanks
seems that would be an improvement, not a bug
Steve Ebersole·11:41 AM
well that assumes that you the entire set of all the @Columns
Gail Badner·11:51 AM
@SteveEbersole we could track if any of length/precision/scale have been explicitly set using a setter; we could allow length/precision/scale to be set once; if an attempt is made to reset length/precision/scale, ignore and log a warning; wdyt?
Steve Ebersole·11:52 AM
well 2 things there
1) that really does nothing about whether it came from insertable=false, updatable=false
Gail Badner·11:53 AM
(true)
Steve Ebersole·11:53 AM
2) i'm ok with that in general, but I'd change to to say you can only call it once with differing values
e.g....
i ought to be able to call setLegth( 5 ) as many times as I want
Gail Badner·11:54 AM
(I realized after writing it that Column does not have contextual information like insertable=false, updatable=false
yes, the same value is fine;
Steve Ebersole·11:54 AM
yeah, so I'm ok with that
Gail Badner·11:55 AM
so, basically first one wins (indeterminate), but we log to show inconsistencies
Gail Badner·12:02 PM
@SteveEbersole , org.hibernate.mapping.Column doesn't have access to contextual information, and there's no way (without changing Column) to determine if, for example, one attribute has @Column(precision=..) and another attribute has @Column(scale=...); I guess I'm ok with that; wdyt?
Steve Ebersole·12:53 PM
well I think it boils down to whether we can effectively handle null for those values
thats been an outstanding problem in Hibernate for years
take setLength, e.g....
ideally, setLength would look like:
public void setLength(int length) {
    if ( this.length != null ) {
        // make sure the values are the same...
        if ( this.length.intValue() != length )

    }
    this.length = length;
}
Show less
Gail Badner·12:57 PM
hmm, how would one set null for length?
since the argument is an int...
Steve Ebersole·12:59 PM
set null?
Gail Badner·12:59 PM
@SteveEbersole  would it break anything if we change the length and argument field to Integer?
Steve Ebersole·1:00 PM
the idea is that the default is null
you only call setXYZ when the value is not null
Gail Badner·1:00 PM
ah, ok
Steve Ebersole·1:00 PM
you could accept nulls too
but
you need to be careful then about setLength( null )
since thats overriding a previously set value (or is a change) if you follow the normal meaning of setter
Gail Badner·1:02 PM
any problem with changing the method signature to take an Integer arg (instead of int)?
normal meaning of setter is last one wins; maybe that's what should happen here along with a warning
I'm not sure if I'm following all of the ramifications; I'm not going to be able to do anything on this before pto, so I'll just capture this conversation in the jira issue and we can work out details later
I need to wrap some things up and I know you're really busy
Steve Ebersole·1:19 PM
the problem is more that something (I forget what exact;y) immediately applies the "defaults" when a particular source does not provide them
and then lots of code work on that assumption (non null)
if you can adjust all those places that would be great
this is ultimately what I want to do to properly support those Type#dictatedSizes and Type#defaultSizes methods
but as you said, that needs to be at a higher level than Column
i just have not found a decent hook point given how we currently process sources