- This topic has 35 replies, 4 voices, and was last updated 18 years, 9 months ago by
.
-
Posts
-
That’s great news. Once the over write bug is fixed, then the problem of having to select each referenced table when mapping will not be as severe and I have a workaround (Just need to check the FK before remapping).
The subclass is no longer being overwritten. However, I’m still forced to select each table that has a FK (and the tables that have FK to it, etc) to the table I’m trying to generate. This is a problem in that I have to overwrite the subclass now to get the FK relationships due to the constructors that are created.
Selecting one table creates something like this for subclass
public Track(String trackTypCd, Long genreId, String langCd….){
super(…);
}Selecting FK tables will create something like this for subclass
public Track(TrackType trackType, Genre genre, Language language…){
super(….);
}Now the subclass will be broken if I change a mapping and regenerate i.e I no longer need a Language for the Track. The AbstractTrack will be fine, but the Track class will contain a constructor that is no longer valid.
Also, hibernate.cfg.xml is not being updated. I can remove the reference manually, regenerate the mapping, and my config files remains the same.
The subclass is no longer being overwritten. However, I’m still forced to select each table that has a FK (and the tables that have FK to it, etc) to the table I’m trying to generate. This is a problem in that I have to overwrite the subclass now to get the FK relationships due to the constructors that are created.
This is a known issue, it is filed but hasn’t been targetted for a release yet. We realize this is a show-stopper for folks with larger tables with more FKs so we are treating it as a high priority item.
On the subclass regeneration front, the policy is simple, don’t regenerate if subclass already exists. Now if you change the mapping, the subclass will obviously be stale. What do you suggest, should we change only the consructors or overwrite the entire class?
Also, hibernate.cfg.xml is not being updated. I can remove the reference manually, regenerate the mapping, and my config files remains the same.
We were never able to reproduce this internally when we ran through simultaneously on different builds over here.
Can you, just for testing, create a new project, add Hib caps to it pointing at your same data source that you are using now, then gen all the tables. Did your cfg.xml file get updated?
Prior to 4.1, if I recall correctly, we had an empty constructor and a constructor that took the PK. Now, we get constructors with all the columns from the table. I think the fix for the problem is the need to fix the problem of having to select all of the tables with FK. With that done, then you could invalidate the generated constructors that are no longer valid due to the new mappings. Maybe there’s a better approach, but overwriting the entire subclass is out of the question.
Creating a new project and adding hibernate capabilities fixes the problem with the config file.
