[jira] Commented: (OPENJPA-626) @JoinColumn with name attribute causes exception on 1.2.0.

["Kevin Sutter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENJPA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602754#action_12602754 ] 

Kevin Sutter commented on OPENJPA-626:
--------------------------------------

Some additional comments from Tim (since he doesn't have a JIRA account yet).  These comments came after I asked about any uniqueness with his scenario since we have several testcases that should be verifying the proper action:

As shown, it - and many similar cases - work properly in 1.0.2 and I'm
not doing anything really odd here, but here's a few items that might
have a bearing on it:

1. This is a PostgreSQL database. An earlier version of openJPA had
problems because it tried to get the Java name from an anonymous foreign
key relationship, but PostgreSQL generates names in the form "$1", "$2",
etc, which aren't good Java names. I've tried to ensure that every
foreign relationship has an explicit Java-friendly name, but I might
have missed something.

2. Nothing excessively outrageous about the database structure, but
there are a fair amount of parent-child-grandchild relationships and
some children might have parents of more than one class type. Also a few
1-1 linkages.

3. I'm also tweaking lazy and eager fetches.

4. The model was originally generated by reverse-engineering the
database, but has been extensively hand-modified since then.

5. The failing project is Spring-based running on Tomcat. It's not
impossible that there could be obscure AOP weaver issues.

None of the above should have a direct impact, but I can't vouch for
indirect ones.

You might want to run tests with SQL tracing on and verify that the
names defined in the resulting SQL are actually the names used and it's
not merely 2 wrongs making a right, so to speak.

I can't think of how to reduce my project down to a test case in a
hurry, but I can set some breakpoints in what I've got if you'll suggest
areas that should be looked at.





> @JoinColumn with name attribute causes exception on 1.2.0. 
> -----------------------------------------------------------
>
>                 Key: OPENJPA-626
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-626
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Michael Dick
>
> Creating Issue on behalf of Tim Holloway. Here's his email to the dev mailing list : 
> @ManyToOne(fetch=FetchType.EAGER, cascade=CascadeType.MERGE)
>        @JoinColumn(name="bus_stop_id")
>        private BusStops busStop;
> Works in release 1.0.2:
> SELECT t0.schedule_stop_id, t1.stop_id, t1.description, t1.elevation,
> t1.in_
> service_date, t1.inbound, t1.latitude, t1.longitude,
> t1.out_service_date, t1.sheltered, t1.street1_block,
> t2.street_direction_id, t2.description, t1.street1_name, t1.street1
> _qualifier, t3.street_type_id, t3.description, t1.street2_block,
> t4.street_direction_id, t4.description, t1.street2_name,
> t1.street2_qualifier, t5.street_type_id, t5.descrip
> tion, t1.waypoint, t0.clock_point, t0.comments, t0.in_service,
> t0.in_service_date, t0.inbound, t0.out_service_date, t0.outbound,
> t0.schedule_id, t0.stop_sequence, t0.terminu
> s, t0.transfer_point FROM public.schedule_stops t0 LEFT OUTER JOIN
> public.bus_stops t1 ON t0.bus_stop_id = t1.stop_id LEFT OUTER JOIN
> public.lk_street_directions t2 ON t1.st
> reet1_direction = t2.street_direction_id LEFT OUTER JOIN
> public.lk_street_types t3 ON t1.street1_type = t3.street_type_id LEFT
> OUTER JOIN public.lk_street_directions t4 ON t
> 1.street2_direction = t4.street_direction_id LEFT OUTER JOIN
> public.lk_street_types t5 ON t1.street2_type = t5.street_type_id WHERE
> t0.schedule_id = ? ORDER BY t0.stop_seque
> nce ASC [params=(int) 50]
> Uses synthesized column name instead of declared name in today's CVS
> snapshot:
> ERROR: column t0.busstop_stop_id does not exist {prepstmnt 17939164
> SELECT t0.schedule_stop_id, t1.stop_id, t1.description, t1.elevation,
> t1.in_service_date, t1.inbound, t1.latitude, t1.longitude,
> t1.out_service_date, t1.sheltered, t1.street1_block,
> t2.street_direction_id, t2.description, t1.street1_name,
> t1.street1_qualifier, t3.street_type_id, t3.description,
> t1.street2_block, t4.street_direction_id, t4.description,
> t1.street2_name, t1.street2_qualifier, t5.street_type_id,
> t5.description, t1.waypoint, t0.clock_point, t0.comments, t0.in_service,
> t0.in_service_date, t0.inbound, t0.out_service_date, t0.outbound,
> t0.SCHEDULE_SCHEDULE_ID, t0.stop_sequence, t0.terminus,
> t0.transfer_point
> FROM public.schedule_stops t0
>  LEFT OUTER JOIN public.bus_stops t1
>  ON t0.BUSSTOP_STOP_ID = t1.stop_id
>  LEFT OUTER JOIN public.lk_street_directions t2
>  ON t1.street1_direction = t2.street_direction_id
>  LEFT OUTER JOIN public.lk_street_types t3 ON t1.street1_type =
> t3.street_type_id LEFT OUTER JOIN public.lk_street_directions t4 ON
> t1.street2_direction = t4.street_direction_id LEFT OUTER JOIN
> public.lk_street_types t5 ON t1.street2_type = t5.street_type_id WHERE
> t0.SCHEDULE_SCHEDULE_ID = ? ORDER BY t0.stop_sequence ASC [params=(int)
> 50]} [code=0, state=42703]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.