The method names in 6.9 follow a new and hugely code-breaking new convention. To avoid touching thousands of lines of code, is there a way to configure the method names of the generated classes to be similar to prior versions of Netbeans. Version 6.9 generates method names using the name of the table, not the name of the primary key. Either way would have been okay, but users have tons of code written against the convention from earlier versions. Can you either roll back the change, or make it configurable?
I'm sorry I don't understand the problem. Please, add more details, test-case will be best. Thanks
I am referring to the Netbeans feature in which it will generate entity classes automatically by analyzing database structure, one entity class per table. The entity classes have a get and set method for each column.
In prior versions of Netbeans, all get and set method names were based directly on the database column names, regardless of whether the column was a foreign key or not. This was an excellent design choice, since it preserved a close match between the Java class and the underlying table.
In version 6.9 of Netbeans, this is broken for foreign keys. The get and set method names for foreign keys no longer have any correlation to the column name, but instead are named for the name of the parent table. In cases where multiple columns in a table refer to the same parent table, it gets worse: the get and set methods are based on the parent table name plus a number.
Example: I have a table called facility, with two audit fields: one called CreatedByUser to keep track of the user who added the facility, and another called ModifiedByUser to keep track of the user who last modified the facility. Both of these columns are foreign keys to the user table.
In prior versions of Netbeans, the entity class facility would have get and set method names of getCreatedByUser(), setCreatedByUser(), getModifiedByUser(), and setModifiedByUser().
In Netbeans 6.9, the entity class facility has get and set method names of getUser(), setUser(), getUser1(), and setUser1().
Of course these new names are not as useful as those made by prior versions of Netbeans, since they lead to very unreadable code.
But the most devastating thing about the problem is that thousands of lines of existing code no longer even compile. I have rolled back to version 6.8 since in its current state version 6.9 cannot be used.
Thanks for your more detailed report. I reassign to persistence team who can analyze the problem.
unfortunately there is no way. there was request to have names more user friendly to avoid lined like myId.myId ad have my.myId instead. it looks better for me.
but according to your samples it may be better to roll back this change but it will be available only in dev build and in next netbeans.
another problem will be code generated in 6.9 will be different in 6.10 if rollback issue 185253.
why "But the most devastating thing about the problem is that thousands of lines of
existing code no longer even compile." it may happen? Is it right after entities generation from db?
Yes, for example in one project I have 127 generated entity classes. When I modify the database schema, I delete and rebuild those classes. When the method signatures (the get and set method names) all change, all of my handwritten code, in hundreds of other classes that references those entity classes, all break -- they don't compile because they refer to method names in the entity classes that no longer exist.
Beyond it being a code-breaking change, I am baffled as to why the naming was changed from version 6.8. The new names are not friendlier. What's clearer, a method name like getModifiedByUser(), or get User2()? The former is what I would have gotten with 6.8, the latter is what 6.9 generates.
I would certainly take advantage of any interim build that rolled back the change, as currently I cannot use 6.9 at all. thanks alot
ok, it looks like mapping options step in entity from db wizard may be a good place to add setting like "use column names for relations", it will be cmpartible with old and with 6.9 behavior even one will require wo more clicks.
http://hg.netbeans.org/web-main/rev/7119d2a3e9d0 options is added.
there is another issue, all options are default on last wizard step on each invocation(aren't saved) but it need to be handled as another issue.
wait for integration message t see what build to use.
Integrated into 'main-golden', will be available in build *201007170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Sergey B. Petrov <email@example.com>
Log: fix #188550 options is added on mappings step
*** Bug 189473 has been marked as a duplicate of this bug. ***
Backported into release692 http://hg.netbeans.org/releases/rev/e1ea39723d9c
Verified in 6.9 patch 2