|
Home > Archive > Apache JDO Project > August 2007 > Implicitly setting @Column's defaultValue parameter
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Implicitly setting @Column's defaultValue parameter
|
|
| cbeams 2007-08-09, 7:11 pm |
| In the case of a PC class with a field declared as
@Column(name = "foo_bar", allowsNull = "false")
int fooBar = 0;
It would be nice if the implementation would implicitly set the
default value for the column, as if the user had typed
@Column(name = "foo_bar", allowsNull = "false", defaultValue = "0")
int fooBar = 0;
This is especially helpful in schema generation scenarios where
incremental changes (ALTER TABLE ADD COLUMN) are being applied to a
schema. Without the defaultValue set, schema generation fails with
an error stating that it can't alter the table because it doesn't
know what to populate into the new column for already existing rows.
This change would also reduce the risk of error-prone duplication
between the programmatically assigned value and the annotation-
declared value (I can't imagine when they wouldn't be the same).
Thanks,
- Chris Beams
| |
| Andy Jefferson 2007-08-10, 1:11 pm |
| > In the case of a PC class with a field declared as
>
> @Column(name =3D "foo_bar", allowsNull =3D "false")
> int fooBar =3D 0;
>
> It would be nice if the implementation would implicitly set the
> default value for the column, as if the user had typed
>
> @Column(name =3D "foo_bar", allowsNull =3D "false", defaultValue =3D "0")
> int fooBar =3D 0;
Hi Chris,
I'm intrigued where you think the implementation is going to find this=20
information. When bytecode is generated (by the compiler) all such=20
initialisations are dumped into available constructor methods and there is =
no=20
obvious way of determining what comes from the users provided constructor,=
=20
what comes from field initialisation, and what comes from static=20
initialisation. Consequently when an enhancer (BCEL, ASM etc) come across t=
he=20
constructor method bytecode they can't separate it out easily.
Adding this to a specification would have to imply the process for how it i=
s=20
possible since a "reference implementation" needs to be written.
Same issue as http://www.jpox.org/servlet/jira/browse/ENHANCER-96
=2D-=20
Andy =A0(Java Persistent Objects - http://www.jpox.org)
| |
| cbeams 2007-08-10, 1:11 pm |
| This did strike my as potentially tricky to implement... perhaps too
much so, it sounds.
- Chris
On Aug 10, 2007, at 6:12 AM, Andy Jefferson wrote:
>
> Hi Chris,
>
> I'm intrigued where you think the implementation is going to find this
> information. When bytecode is generated (by the compiler) all such
> initialisations are dumped into available constructor methods and
> there is no
> obvious way of determining what comes from the users provided
> constructor,
> what comes from field initialisation, and what comes from static
> initialisation. Consequently when an enhancer (BCEL, ASM etc) come
> across the
> constructor method bytecode they can't separate it out easily.
>
> Adding this to a specification would have to imply the process for
> how it is
> possible since a "reference implementation" needs to be written.
> Same issue as http://www.jpox.org/servlet/jira/browse/ENHANCER-96
>
>
>
> --
> Andy (Java Persistent Objects - http://www.jpox.org)
|
|
|
|
|