Home » Eclipse Projects » Dali » Dali Galileo - Entities and properties naming stragety
| | | |
Re: Dali Galileo - Entities and properties naming stragety [message #485973 is a reply to message #485936] |
Tue, 15 September 2009 17:53 |
Marc Schlegel Messages: 92 Registered: July 2009 |
Member |
|
|
Thanks for your answer Brian
> your problem is not completely clear. Is this related to Dali Entity
> Generation?
> Or DDL Generation? What database platform are you using?
Well, I use the contextmenu on the project "JPA Tools -> Generate Tables from
Entites" and I am using a local MySql.
>
> Re: the examples you give:
>
> - The 'name' field might not resolve to a column if you are using a
> case-sensitive database (e.g. MS SQL Server) and the case does not
> match. In your example the field name is "name" while you indicate the
> database column name is "Name" - the case of these identifiers does not
> match.
As mentioned above, I use MySql. The explanation makes sense, but why is the
column then not creates as "name" rather than "NAME" by default? Most of the
databases I've seen usually use uppercase table-, columnnames, so why is this
not recognized by default (or is this a jpa thing)? Every additional annotation
makes my code less readable (I know that JPA adds the @Basic for every field
automatically)
Dont get me wrong, the work Jpa and Dali are doing is awesome and I know that a
lot of effort is necessary for this and maybe this has been already addressed
for later releases.
regards
Marc
>
> - The 'customer' field has a validation error because if you do not
> specify otherwise, Dali calculates the JPA spec-defined default column
> name and looks for it on your database. The validation error indicates
> the column is not found and tells you what the calculated default name is.
>
> Brian
>
>
> Marc Schlegel wrote:
>> Hello Everyone
>>
>> I was just about to write about a similar issue, so I think I just
>> attach it
>> here (hope that right).
>>
>> The Dali validation always claims that it cannot resolve the column to
>> my fields.
>>
>> Example
>> @Entity
>> public class Person extends EntityBase {
>>
>> private string name;
>> ...
>> }
>>
>> It will not be able to resolve the table-column NAME which is created
>> by dali.
>> To get this to work I have to name the column directly
>>
>> @Entity
>> public class Person extends EntityBase {
>>
>> @Column(name = "Name")
>> private string name;
>> ...
>> }
>>
>> then recreate the schema and then this works.
>>
>> It gets a little bit worse for @ManyToOne. For example
>> @OneToMany(mappedBy = "customer")
>> private List<BankAccount> accounts = new ArrayList<BankAccount>();
>> works, but the bidirectional mapping
>> @ManyToOne
>> private Customer customer;
>> claims "customer_Id" cannot be resolved.
>>
>> I was googling this quite a bit because I thought the mistake is on my
>> side, but
>> all tutorials I've found use the above code (no attributeoverride or
>> something
>> like that).
>>
>> Thanks
>>
>>
>>> Lionel,
>>>
>>> This appears to be an unfortunate regression in Entity Generation for
>>> Galileo. I have entered bug 285032* for this issue and targeted the fix
>>> for the first Galileo maintenance release. Thanks for bringing this to
>>> our attention.
>>>
>>> I can't think of a good workaround for this issue. You may want to
>>> generate your entities in a previous version of Dali and import them
>>> into your current workspace.
>>>
>>> Neil
>>>
>>>
>>> * https://bugs.eclipse.org/bugs/show_bug.cgi?id=285032
>>>
>>>
>>>
>>> Lionel wrote:
>>>
>>>> Hello,
>>>> Is it possible to configure Dali's naming strategy with Galileo ?
>>>> The new naming strategy uses the name of the table "as is" instead of
>>>> using
>>>> java naming conventions.
>>>> If the table is named "user_group" the generated entity is named
>>>> User_group.java instead of UserGroup.java as it was with Ganymede.
>>>> Is it possible to change this behaviour instead of renaming manually
>>>> all entities and all fields (which is not humanly possible) ?
>>>> Thanks
>>>
|
|
|
Re: Dali Galileo - Entities and properties naming stragety [message #486042 is a reply to message #485973] |
Wed, 16 September 2009 04:29 |
Brian Vosburgh Messages: 137 Registered: July 2009 |
Senior Member |
|
|
Marc,
there are probably a couple of issues here.
Dali treats MySQL as a case-sensitive database. This is because MySQL is a bit
whacked when it comes to case-sensitivity (e.g. the case-sensitivity of table
names depends on the case-sensitivity of the underlying O/S file system). As a
result, Dali takes the conservative approach of validating the various database
objects with case-sensitive identifiers. So, to continue with your example, if
your Java field name is "name" then the MySQL column must also be named "name"
(not "Name" or "NAME"). If the names do not match, Dali will generate a
validation error.
The other issue is that Dali actually "out-sources" the creation of tables to
your JPA runtime library. (Part of our effort to integrate with the rest of the
Eclipse ecosystem. :-) ) Since we ship with EclipseLink, I'm guessing you have
configured your JPA project to use EclipseLink. If that is the case, when you
execute "JPA Tools -> Generate Tables from Entities" Dali is delegating to the
EclipseLink runtime library to do the actual work. If the output is problematic
for you, you might want to take it up with the EclipseLink project.
As to how we "should" be treating case-sensitivity: the JPA 1.0 spec does not
address case-sensitivity at all. The many examples in the spec imply
case-*in*sensitivity; but the actual behavior is going to be dependent on your
JPA runtime implementation and database server. Dali has attempted to deal with
this in as helpful a way as possible (e.g. ignoring or respecting case depending
on your target database server). Maybe unfortunately in this case, Dali's
interaction with MySQL is case-sensitive. You might try PosgreSQL? :-)
Brian
Marc Schlegel wrote:
> Thanks for your answer Brian
>
>
>> your problem is not completely clear. Is this related to Dali Entity
>> Generation?
>> Or DDL Generation? What database platform are you using?
>
> Well, I use the contextmenu on the project "JPA Tools -> Generate Tables from
> Entites" and I am using a local MySql.
>
>> Re: the examples you give:
>>
>> - The 'name' field might not resolve to a column if you are using a
>> case-sensitive database (e.g. MS SQL Server) and the case does not
>> match. In your example the field name is "name" while you indicate the
>> database column name is "Name" - the case of these identifiers does not
>> match.
>
> As mentioned above, I use MySql. The explanation makes sense, but why is the
> column then not creates as "name" rather than "NAME" by default? Most of the
> databases I've seen usually use uppercase table-, columnnames, so why is this
> not recognized by default (or is this a jpa thing)? Every additional annotation
> makes my code less readable (I know that JPA adds the @Basic for every field
> automatically)
>
> Dont get me wrong, the work Jpa and Dali are doing is awesome and I know that a
> lot of effort is necessary for this and maybe this has been already addressed
> for later releases.
>
> regards
> Marc
>
>> - The 'customer' field has a validation error because if you do not
>> specify otherwise, Dali calculates the JPA spec-defined default column
>> name and looks for it on your database. The validation error indicates
>> the column is not found and tells you what the calculated default name is.
>>
>> Brian
>>
>>
>> Marc Schlegel wrote:
>>> Hello Everyone
>>>
>>> I was just about to write about a similar issue, so I think I just
>>> attach it
>>> here (hope that right).
>>>
>>> The Dali validation always claims that it cannot resolve the column to
>>> my fields.
>>>
>>> Example
>>> @Entity
>>> public class Person extends EntityBase {
>>>
>>> private string name;
>>> ...
>>> }
>>>
>>> It will not be able to resolve the table-column NAME which is created
>>> by dali.
>>> To get this to work I have to name the column directly
>>>
>>> @Entity
>>> public class Person extends EntityBase {
>>>
>>> @Column(name = "Name")
>>> private string name;
>>> ...
>>> }
>>>
>>> then recreate the schema and then this works.
>>>
>>> It gets a little bit worse for @ManyToOne. For example
>>> @OneToMany(mappedBy = "customer")
>>> private List<BankAccount> accounts = new ArrayList<BankAccount>();
>>> works, but the bidirectional mapping
>>> @ManyToOne
>>> private Customer customer;
>>> claims "customer_Id" cannot be resolved.
>>>
>>> I was googling this quite a bit because I thought the mistake is on my
>>> side, but
>>> all tutorials I've found use the above code (no attributeoverride or
>>> something
>>> like that).
>>>
>>> Thanks
>>>
>>>
>>>> Lionel,
>>>>
>>>> This appears to be an unfortunate regression in Entity Generation for
>>>> Galileo. I have entered bug 285032* for this issue and targeted the fix
>>>> for the first Galileo maintenance release. Thanks for bringing this to
>>>> our attention.
>>>>
>>>> I can't think of a good workaround for this issue. You may want to
>>>> generate your entities in a previous version of Dali and import them
>>>> into your current workspace.
>>>>
>>>> Neil
>>>>
>>>>
>>>> * https://bugs.eclipse.org/bugs/show_bug.cgi?id=285032
>>>>
>>>>
>>>>
>>>> Lionel wrote:
>>>>
>>>>> Hello,
>>>>> Is it possible to configure Dali's naming strategy with Galileo ?
>>>>> The new naming strategy uses the name of the table "as is" instead of
>>>>> using
>>>>> java naming conventions.
>>>>> If the table is named "user_group" the generated entity is named
>>>>> User_group.java instead of UserGroup.java as it was with Ganymede.
>>>>> Is it possible to change this behaviour instead of renaming manually
>>>>> all entities and all fields (which is not humanly possible) ?
>>>>> Thanks
|
|
| | | |
Re: Dali Galileo - Entities and properties naming stragety [message #617516 is a reply to message #485936] |
Tue, 15 September 2009 17:53 |
Marc Schlegel Messages: 92 Registered: July 2009 |
Member |
|
|
Thanks for your answer Brian
> your problem is not completely clear. Is this related to Dali Entity
> Generation?
> Or DDL Generation? What database platform are you using?
Well, I use the contextmenu on the project "JPA Tools -> Generate Tables from
Entites" and I am using a local MySql.
>
> Re: the examples you give:
>
> - The 'name' field might not resolve to a column if you are using a
> case-sensitive database (e.g. MS SQL Server) and the case does not
> match. In your example the field name is "name" while you indicate the
> database column name is "Name" - the case of these identifiers does not
> match.
As mentioned above, I use MySql. The explanation makes sense, but why is the
column then not creates as "name" rather than "NAME" by default? Most of the
databases I've seen usually use uppercase table-, columnnames, so why is this
not recognized by default (or is this a jpa thing)? Every additional annotation
makes my code less readable (I know that JPA adds the @Basic for every field
automatically)
Dont get me wrong, the work Jpa and Dali are doing is awesome and I know that a
lot of effort is necessary for this and maybe this has been already addressed
for later releases.
regards
Marc
>
> - The 'customer' field has a validation error because if you do not
> specify otherwise, Dali calculates the JPA spec-defined default column
> name and looks for it on your database. The validation error indicates
> the column is not found and tells you what the calculated default name is.
>
> Brian
>
>
> Marc Schlegel wrote:
>> Hello Everyone
>>
>> I was just about to write about a similar issue, so I think I just
>> attach it
>> here (hope that right).
>>
>> The Dali validation always claims that it cannot resolve the column to
>> my fields.
>>
>> Example
>> @Entity
>> public class Person extends EntityBase {
>>
>> private string name;
>> ...
>> }
>>
>> It will not be able to resolve the table-column NAME which is created
>> by dali.
>> To get this to work I have to name the column directly
>>
>> @Entity
>> public class Person extends EntityBase {
>>
>> @Column(name = "Name")
>> private string name;
>> ...
>> }
>>
>> then recreate the schema and then this works.
>>
>> It gets a little bit worse for @ManyToOne. For example
>> @OneToMany(mappedBy = "customer")
>> private List<BankAccount> accounts = new ArrayList<BankAccount>();
>> works, but the bidirectional mapping
>> @ManyToOne
>> private Customer customer;
>> claims "customer_Id" cannot be resolved.
>>
>> I was googling this quite a bit because I thought the mistake is on my
>> side, but
>> all tutorials I've found use the above code (no attributeoverride or
>> something
>> like that).
>>
>> Thanks
>>
>>
>>> Lionel,
>>>
>>> This appears to be an unfortunate regression in Entity Generation for
>>> Galileo. I have entered bug 285032* for this issue and targeted the fix
>>> for the first Galileo maintenance release. Thanks for bringing this to
>>> our attention.
>>>
>>> I can't think of a good workaround for this issue. You may want to
>>> generate your entities in a previous version of Dali and import them
>>> into your current workspace.
>>>
>>> Neil
>>>
>>>
>>> * https://bugs.eclipse.org/bugs/show_bug.cgi?id=285032
>>>
>>>
>>>
>>> Lionel wrote:
>>>
>>>> Hello,
>>>> Is it possible to configure Dali's naming strategy with Galileo ?
>>>> The new naming strategy uses the name of the table "as is" instead of
>>>> using
>>>> java naming conventions.
>>>> If the table is named "user_group" the generated entity is named
>>>> User_group.java instead of UserGroup.java as it was with Ganymede.
>>>> Is it possible to change this behaviour instead of renaming manually
>>>> all entities and all fields (which is not humanly possible) ?
>>>> Thanks
>>>
|
|
|
Re: Dali Galileo - Entities and properties naming stragety [message #617607 is a reply to message #485973] |
Wed, 16 September 2009 04:29 |
Brian Vosburgh Messages: 137 Registered: July 2009 |
Senior Member |
|
|
Marc,
there are probably a couple of issues here.
Dali treats MySQL as a case-sensitive database. This is because MySQL is a bit
whacked when it comes to case-sensitivity (e.g. the case-sensitivity of table
names depends on the case-sensitivity of the underlying O/S file system). As a
result, Dali takes the conservative approach of validating the various database
objects with case-sensitive identifiers. So, to continue with your example, if
your Java field name is "name" then the MySQL column must also be named "name"
(not "Name" or "NAME"). If the names do not match, Dali will generate a
validation error.
The other issue is that Dali actually "out-sources" the creation of tables to
your JPA runtime library. (Part of our effort to integrate with the rest of the
Eclipse ecosystem. :-) ) Since we ship with EclipseLink, I'm guessing you have
configured your JPA project to use EclipseLink. If that is the case, when you
execute "JPA Tools -> Generate Tables from Entities" Dali is delegating to the
EclipseLink runtime library to do the actual work. If the output is problematic
for you, you might want to take it up with the EclipseLink project.
As to how we "should" be treating case-sensitivity: the JPA 1.0 spec does not
address case-sensitivity at all. The many examples in the spec imply
case-*in*sensitivity; but the actual behavior is going to be dependent on your
JPA runtime implementation and database server. Dali has attempted to deal with
this in as helpful a way as possible (e.g. ignoring or respecting case depending
on your target database server). Maybe unfortunately in this case, Dali's
interaction with MySQL is case-sensitive. You might try PosgreSQL? :-)
Brian
Marc Schlegel wrote:
> Thanks for your answer Brian
>
>
>> your problem is not completely clear. Is this related to Dali Entity
>> Generation?
>> Or DDL Generation? What database platform are you using?
>
> Well, I use the contextmenu on the project "JPA Tools -> Generate Tables from
> Entites" and I am using a local MySql.
>
>> Re: the examples you give:
>>
>> - The 'name' field might not resolve to a column if you are using a
>> case-sensitive database (e.g. MS SQL Server) and the case does not
>> match. In your example the field name is "name" while you indicate the
>> database column name is "Name" - the case of these identifiers does not
>> match.
>
> As mentioned above, I use MySql. The explanation makes sense, but why is the
> column then not creates as "name" rather than "NAME" by default? Most of the
> databases I've seen usually use uppercase table-, columnnames, so why is this
> not recognized by default (or is this a jpa thing)? Every additional annotation
> makes my code less readable (I know that JPA adds the @Basic for every field
> automatically)
>
> Dont get me wrong, the work Jpa and Dali are doing is awesome and I know that a
> lot of effort is necessary for this and maybe this has been already addressed
> for later releases.
>
> regards
> Marc
>
>> - The 'customer' field has a validation error because if you do not
>> specify otherwise, Dali calculates the JPA spec-defined default column
>> name and looks for it on your database. The validation error indicates
>> the column is not found and tells you what the calculated default name is.
>>
>> Brian
>>
>>
>> Marc Schlegel wrote:
>>> Hello Everyone
>>>
>>> I was just about to write about a similar issue, so I think I just
>>> attach it
>>> here (hope that right).
>>>
>>> The Dali validation always claims that it cannot resolve the column to
>>> my fields.
>>>
>>> Example
>>> @Entity
>>> public class Person extends EntityBase {
>>>
>>> private string name;
>>> ...
>>> }
>>>
>>> It will not be able to resolve the table-column NAME which is created
>>> by dali.
>>> To get this to work I have to name the column directly
>>>
>>> @Entity
>>> public class Person extends EntityBase {
>>>
>>> @Column(name = "Name")
>>> private string name;
>>> ...
>>> }
>>>
>>> then recreate the schema and then this works.
>>>
>>> It gets a little bit worse for @ManyToOne. For example
>>> @OneToMany(mappedBy = "customer")
>>> private List<BankAccount> accounts = new ArrayList<BankAccount>();
>>> works, but the bidirectional mapping
>>> @ManyToOne
>>> private Customer customer;
>>> claims "customer_Id" cannot be resolved.
>>>
>>> I was googling this quite a bit because I thought the mistake is on my
>>> side, but
>>> all tutorials I've found use the above code (no attributeoverride or
>>> something
>>> like that).
>>>
>>> Thanks
>>>
>>>
>>>> Lionel,
>>>>
>>>> This appears to be an unfortunate regression in Entity Generation for
>>>> Galileo. I have entered bug 285032* for this issue and targeted the fix
>>>> for the first Galileo maintenance release. Thanks for bringing this to
>>>> our attention.
>>>>
>>>> I can't think of a good workaround for this issue. You may want to
>>>> generate your entities in a previous version of Dali and import them
>>>> into your current workspace.
>>>>
>>>> Neil
>>>>
>>>>
>>>> * https://bugs.eclipse.org/bugs/show_bug.cgi?id=285032
>>>>
>>>>
>>>>
>>>> Lionel wrote:
>>>>
>>>>> Hello,
>>>>> Is it possible to configure Dali's naming strategy with Galileo ?
>>>>> The new naming strategy uses the name of the table "as is" instead of
>>>>> using
>>>>> java naming conventions.
>>>>> If the table is named "user_group" the generated entity is named
>>>>> User_group.java instead of UserGroup.java as it was with Ganymede.
>>>>> Is it possible to change this behaviour instead of renaming manually
>>>>> all entities and all fields (which is not humanly possible) ?
>>>>> Thanks
|
|
|
Goto Forum:
Current Time: Thu Sep 19 15:21:02 GMT 2024
Powered by FUDForum. Page generated in 0.04429 seconds
|