You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Tim Holloway <ti...@mousetech.com> on 2008/06/02 22:16:09 UTC
JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
@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]
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Tim Holloway <ti...@mousetech.com>.
Thanks Kevin,
I don't have a Jira account. Could you open the ticket for me?
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.
Tim
On Thu, 2008-06-05 at 09:13 -0500, Kevin Sutter wrote:
> Hi Tim,
> >From your description, this looks to be a valid concern. I just did a quick
> search of our testcases and found several cases of the @JoinColumn
> annotation, so I am surprised that you're hitting a problem. But, I did
> notice in several of the cases that although we used the "name" element, we
> didn't change the expected generated name, so I'm not sure of the benefit in
> those cases... But, there were several other scenarios where the name was
> unique and different.
>
> I'll continue to take a look, but in the mean time, you might want to open a
> JIRA Issue. If possible, a simple testcase would also help define the
> problem (since our testcase must not be finding it). There must be
> something slightly unique with your application as compared to the ones used
> in our testing.
>
> Thanks,
> Kevin
>
> On Thu, Jun 5, 2008 at 6:10 AM, Tim Holloway <ti...@mousetech.com> wrote:
>
> > No comments?
> >
> > On Mon, 2008-06-02 at 16:16 -0400, Tim Holloway wrote:
> > > @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]
> >
> >
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Tim,
>From your description, this looks to be a valid concern. I just did a quick
search of our testcases and found several cases of the @JoinColumn
annotation, so I am surprised that you're hitting a problem. But, I did
notice in several of the cases that although we used the "name" element, we
didn't change the expected generated name, so I'm not sure of the benefit in
those cases... But, there were several other scenarios where the name was
unique and different.
I'll continue to take a look, but in the mean time, you might want to open a
JIRA Issue. If possible, a simple testcase would also help define the
problem (since our testcase must not be finding it). There must be
something slightly unique with your application as compared to the ones used
in our testing.
Thanks,
Kevin
On Thu, Jun 5, 2008 at 6:10 AM, Tim Holloway <ti...@mousetech.com> wrote:
> No comments?
>
> On Mon, 2008-06-02 at 16:16 -0400, Tim Holloway wrote:
> > @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]
>
>
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Tim Holloway <ti...@mousetech.com>.
Mike,
I didn't realize I could open my own account. Done.
Thanks,
Tim
On Thu, 2008-06-05 at 12:57 -0500, Michael Dick wrote:
> Hi Tim,
>
> I've opened a JIRA on your behalf :
> *OPENJPA-626<https://issues.apache.org/jira/browse/OPENJPA-626>.
> *It's relatively painless to create a JIRA account and you'll need one to
> update the issue. It would be helpful for us (and anyone else who hits this
> problem) if we could document the solution to the problem in the issue.
>
> It's no big deal if you don't open an account though, just putting in my
> $0.02.
>
> -Mike
>
> On Thu, Jun 5, 2008 at 11:02 AM, Jeremy Bauer <te...@gmail.com> wrote:
>
> > Hi Tim,
> >
> > A SQL caching performance enhancement was added in 1.2.0 that speeds
> > up findBy and certain eager fetch operations (which are used in your
> > application). It has been through rigorous testing, but it may be
> > worthwhile to verify that the cache isn't causing the problem. If
> > you'd like to try running with the cache disabled, add this property
> > to your persistence.xml.
> >
> > <property name="openjpa.jdbc.QuerySQLCache" value="false"/>
> >
> > -Jeremy
> >
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Michael Dick <mi...@gmail.com>.
Hi Tim,
I've opened a JIRA on your behalf :
*OPENJPA-626<https://issues.apache.org/jira/browse/OPENJPA-626>.
*It's relatively painless to create a JIRA account and you'll need one to
update the issue. It would be helpful for us (and anyone else who hits this
problem) if we could document the solution to the problem in the issue.
It's no big deal if you don't open an account though, just putting in my
$0.02.
-Mike
On Thu, Jun 5, 2008 at 11:02 AM, Jeremy Bauer <te...@gmail.com> wrote:
> Hi Tim,
>
> A SQL caching performance enhancement was added in 1.2.0 that speeds
> up findBy and certain eager fetch operations (which are used in your
> application). It has been through rigorous testing, but it may be
> worthwhile to verify that the cache isn't causing the problem. If
> you'd like to try running with the cache disabled, add this property
> to your persistence.xml.
>
> <property name="openjpa.jdbc.QuerySQLCache" value="false"/>
>
> -Jeremy
>
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Jeremy Bauer <te...@gmail.com>.
Hi Tim,
A SQL caching performance enhancement was added in 1.2.0 that speeds
up findBy and certain eager fetch operations (which are used in your
application). It has been through rigorous testing, but it may be
worthwhile to verify that the cache isn't causing the problem. If
you'd like to try running with the cache disabled, add this property
to your persistence.xml.
<property name="openjpa.jdbc.QuerySQLCache" value="false"/>
-Jeremy
Re: JoinColumn annotation broken in openjpa-1.2.0-SNAPSHOT?
Posted by Tim Holloway <ti...@mousetech.com>.
No comments?
On Mon, 2008-06-02 at 16:16 -0400, Tim Holloway wrote:
> @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]