Charles,
Thanks for the suggestion. I have tried CVS HEAD and I still get the
same incorrect behavior.
I'm still unclear whether OJB even *expects* to get this query right,
because it doesn't know that 'com' is actually a property of the
abstract superclass. That is, when it follows the 'abs' relationship,
it reaches a class-descriptor which has no field-descriptors, and
indeed it seems to at least partially stop interpreting the path at
this point. But this class-descriptor does have two extent-classes
which each have identical 'com' relationships leading to a class which
does have the 'p' property.
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
>>>>> Charles Anthony writes:
Charles> I have a hunch - quite possibly misplaced - that this may
Charles> have something to do the bug I reported in the thhread
Charles> entitled. "Criteria.setClassPath - the saga continues"
Charles> Although you are using an ODMG query, when the query is
Charles> parsed, it does generate a standard
Charles> QueryByCriteria. QueryByCriteria was getting the wrong
Charles> class descriptor when paths of > 1 sement were used. This
Charles> would lead to the attribute name being passed to the
Charles> query, as opposed to the column name.
Charles> Jakob fixed this in CVS last night.
> -----Original Message-----
> From: Steve Clark [mailto:[EMAIL PROTECTED]
> Sent: 03 March 2004 19:56
> To: OJB Users List
> Subject: Re: Extent problem with ODMG
>
>
> I'm still having this problem, so I'm going to try again.
>
> Using ODMG, RC5, Oracle 9i.
>
> Summary:
> - Class A has a 1-to-1 relationship 'abs' to an abstract
> superclass S
> - Class S has concrete subclasses B and C
> - Classes B and C share a common relationship 'com' to another
> class D; this relationship is defined in the superclass S
> - Class D has a property 'p'
> - A, B, C, and D map to distinct tables
>
> I am trying to retrieve all A's which have a given value for 'p' in
> the D associated with the related B or C (whichever one it is). So:
>
> select x from A where A.abs.com.p = ?
>
> A.abs has type S, the abstract superclass; A.abs.com has type D. This
> means that the query needs to generate some sort of interesting join
> to check for both possible paths to D (via B or C), knowing that
> either B or C will have exactly one row satisfying the join
> condition(s). In pseudocode:
>
> select x from A where
> if A.abs instanceof B then ((B) A.abs).com.p = ?
> else if A.abs instanceof C then ((C) A.abs).com.p = ?
>
> Should I expect this to work? The SQL query which is being generated
> is not only incorrect but invalid: OJB does not rewrite 'p', and in
> fact does not even mention D at all. I assume this has to do with
> the fact that the repository doesn't record the presence of the
> relationship 'com' in the abstract superclass, but only in the
> subclasses. Queries starting from B or C and following the 'com'
> relationship work fine. Am I out of luck, or is there some way I can
> get a working query out of this?
>
> thanks for any insights,
> Steve Clark
> Technology Applications Team
> Natural Resources Research Center/USGS
> [EMAIL PROTECTED]
> (970)226-9291
>
> PS: Original message below. Name mappings:
>
> A = PartnerImpl
> B = SubSiteImpl
> C = TechAssistImpl
> D = SiteImpl
> S = AccomplishmentImpl
>
> abs = accomp
> com = site
> p = habTypeCode
>
> sc> I'm having a problem with extents in ODMG. OJB is generating
> sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm
> sc> using RC5.
>
> sc> My data model consists of Sites, which have collections of
> sc> each of two kinds of Accomplishments (SubSites and
> sc> TechAssists). An Accomplishment has a collection of Partners.
> sc> In the reverse direction, each Partner is associated with
> sc> exactly one Accomplishment (either a SubSite or a TechAssist),
> sc> and an Accomplishment knows about its parent Site. My
> sc> repository looks like this:
>
> sc> <!-- - - - - - - Site - - - - - - -->
>
> sc> <class-descriptor
> sc> class="gov.doi.habits.dataobjects.SiteImpl"
> sc> table="SITE_DETAIL"
> sc> proxy="dynamic">
>
> sc> <field-descriptor
> sc> name="siteKey"
> sc> column="SITE_KEY"
> sc> jdbc-type="INTEGER"
> sc> primarykey="true"
> sc> autoincrement="true"/>
>
> sc> <field-descriptor
> sc> name="habTypeCode"
> sc> column="HAB_TYPE_CODE"
> sc> jdbc-type="INTEGER" />
>
> sc> <collection-descriptor
> sc> name="subSites"
> sc> element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl"
> sc> collection-class="org.apache.ojb.broker.util.collections.Manag
> eableArrayList">
> sc> <inverse-foreignkey field-ref="siteKey" />
> sc> </collection-descriptor>
>
> sc> <collection-descriptor
> sc> name="techAssists"
> sc> element-class-ref="gov.doi.habits.dataobjects.TechAssistImpl"
> sc>
> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList">
> sc> <inverse-foreignkey field-ref="siteKey" />
> sc> </collection-descriptor>
> sc> </class-descriptor>
>
> sc> <!-- - - - - - - Accomplishment - - - - - - -->
>
> sc> <class-descriptor
> sc> class="gov.doi.habits.dataobjects.AccomplishmentImpl" >
>
> sc> <extent-class class-ref="gov.doi.habits.dataobjects.SubSiteImpl" />
> sc> <extent-class class-ref="gov.doi.habits.dataobjects.AssistImpl" />
> sc> </class-descriptor>
>
> sc> <!-- - - - - - - SubSite - - - - - - -->
>
> sc> <class-descriptor
> sc> class="gov.doi.habits.dataobjects.SubSiteImpl"
> sc> table="SUB_SITE_DETAIL"
> sc> proxy="dynamic">
>
> sc> <field-descriptor
> sc> name="accompKey"
> sc> column="ACCOMP_KEY"
> sc> jdbc-type="INTEGER"
> sc> primarykey="true"
> sc> autoincrement="true"
> sc> sequence-name="SEQ_ACCOMP_DETAIL" />
>
> sc> <field-descriptor
> sc> name="siteKey"
> sc> column="SITE_KEY"
> sc> jdbc-type="INTEGER" />
>
> sc> <reference-descriptor
> sc> name="site"
> sc> class-ref="gov.doi.habits.dataobjects.SiteImpl">
> sc> <foreignkey field-ref="siteKey" />
> sc> </reference-descriptor>
>
> sc> <collection-descriptor
> sc> name="partners"
> sc> element-class-ref="gov.doi.habits.dataobjects.PartnerImpl"
> sc>
> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList">
> sc> <inverse-foreignkey field-ref="accompKey" />
> sc> </collection-descriptor>
> sc> </class-descriptor>
>
> sc> <!-- - - - - - - TechAssist - - - - - - -->
>
> sc> <class-descriptor
> sc> class="gov.doi.habits.dataobjects.TechAssistImpl"
> sc> table="ASSIST_DETAIL"
> sc> proxy="dynamic">
>
> sc> <field-descriptor
> sc> name="accompKey"
> sc> column="ACCOMP_KEY"
> sc> jdbc-type="INTEGER"
> sc> primarykey="true"
> sc> autoincrement="true"
> sc> sequence-name="SEQ_ACCOMP_DETAIL" />
>
> sc> <field-descriptor
> sc> name="siteKey"
> sc> column="SITE_KEY"
> sc> jdbc-type="INTEGER" />
>
> sc> <reference-descriptor
> sc> name="site"
> sc> class-ref="gov.doi.habits.dataobjects.SiteImpl">
> sc> <foreignkey field-ref="siteKey" />
> sc> </reference-descriptor>
>
> sc> <collection-descriptor
> sc> name="partners"
> sc> element-class-ref="gov.doi.habits.dataobjects.PartnerImpl"
> sc>
> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList">
> sc> <inverse-foreignkey field-ref="accompKey" />
> sc> </collection-descriptor>
> sc> </class-descriptor>
>
> sc> <!-- - - - - - - Partner - - - - - - -->
>
> sc> <class-descriptor
> sc> class="gov.doi.habits.dataobjects.PartnerImpl"
> sc> table="PARTNER_DETAIL"
> sc> proxy="dynamic">
>
> sc> <field-descriptor
> sc> name="partnerKey"
> sc> column="PARTNER_KEY"
> sc> jdbc-type="INTEGER"
> sc> primarykey="true"
> sc> autoincrement="true"/>
>
> sc> <field-descriptor
> sc> name="accompKey"
> sc> column="ACCOMP_KEY"
> sc> jdbc-type="INTEGER"/>
>
> sc> <reference-descriptor
> sc> name="accomp"
> sc> class-ref="gov.doi.habits.dataobjects.AccomplishmentImpl">
> sc> <foreignkey field-ref="accompKey"/>
> sc> </reference-descriptor>
> sc> </class-descriptor>
>
> sc> My query looks like this:
>
> sc> 15:41:13,896 DEBUG [] accesslayer.JdbcAccessImpl
> sc> (JdbcAccessImpl.java:282) - executeQuery : Query from class
> sc> gov.doi.habits.dataobjects.PartnerImpl where
> sc> [accomp.site.habTypeCode IN [1]]
>
> sc> Note that partner.accomp is an Accomplishment (the abstract
> sc> superclass); both extents (SubSite and TechAssist) have a site
> sc> relationship.
>
> sc> The generated SQL looks like this:
>
> sc> 15:41:13,901 DEBUG [] sql.SqlGeneratorDefaultImpl
> sc> (SqlGeneratorDefaultImpl.java:200) - SQL:SELECT DISTINCT
> sc> A0.ACCOMP_KEY,A0.PARTNER_KEY FROM PARTNER_DETAIL
> sc> A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL A1E1 WHERE
> sc> A0.ACCOMP_KEY=A1.ACCOMP_KEY(+) AND
> sc> A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND ((habTypeCode IN ( ? )
> sc> OR habTypeCode IN ( ? )))
>
> sc> Note that SITE_DETAIL is not even included in the query, and
> sc> habTypeCode as a result is not rewritten to the appropriate
> sc> column name.
>
> sc> I think the correct query would be more like this:
>
> sc> SELECT DISTINCT A0.ACCOMP_KEY,A0.PARTNER_KEY
> sc> FROM PARTNER_DETAIL A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL
> sc> A1E1,SITE_DETAIL A2 WHERE ((A0.ACCOMP_KEY=A1.ACCOMP_KEY(+)
> sc> AND A1.SITE_KEY=A2.SITE_KEY) OR
> sc> (A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND
> sc> A1E1.SITE_KEY=A2.SITE_KEY)) AND
> sc> (A2.HAB_TYPE_CODE IN ( ? ))
>
> sc> ... though I'm not sure that's exactly right even.
>
> sc> Is there a way to get working SQL out of this OQL?
>
> sc> thanks,
> sc> --
> sc> Steve Clark
> sc> Technology Applications Team
> sc> Natural Resources Research Center/USGS
> sc> [EMAIL PROTECTED]
> sc> (970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
