hi mark,

> I guess I just don't see why a regular extent query will work, but when
> joining against an extent class, it fails.
when you do a regular query (ie: query for CMSEntries matching some
criteria) the extents are handled by
PersistenceBroker#getIteratorFromQuery().

when retrieving Keywords where CMSEntry.category = abc you are using
pathExpressions and they are handled by the SqlStatement.
imo this case is not as easy (well it also took it's time...) as the regular
query. to solve this problem we'll have to resolve each pathExpression into
one ore many tables and will have to add additional criteria to the
where-statement.

select from keyword a join(cmsentry b) join(cmsentrySub1 c)
join(cmsentrySub2 d)
where b.category = abc or c.category = abc or d.category = abc

if all your cmsentries are mapped to the same table the above query will
only have to join one cmsentry table.

hth
jakob

----- Original Message -----
From: "Mark Howell" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Thursday, October 10, 2002 10:26 PM
Subject: Re: pathExpressions are NOT extent aware


> Hi Jakob,
>
> Specifically, my current dilemma is this:
>
>           *    1            *    1
> [Keyword] ------ [CMSEntry] ------ [Category]
>  id               id                id
>  cmsentry         categoryId        name
>  cmsentryId       category
>  keyword          ownerId
>
>
> CMSEntry is an abstract base class with (currently) six children.  Each
> Keyword contains a reference to a CMSEntry, and each CMSEntry contains a
> reference to a Category.
>
> I can perform a search on the keyword table and get instances of
> CMSEntrys, but I cannot join against any properties of the CMSEntry
> entities.  For example, I would like to do:
>
> criteria.addIn("keyword", keywordVector);
> criteria.addEqualTo("cmsentry.ownerId", user.getId());
> criteria.addEqualTo("cmsentry.categoryId", category.getId());
> (or, for the sake of argument)
> criteria.addEqualTo("cmsentry.category.name", "Images");
>
> query = QueryFactory.newQuery(Keyword.class, criteria);
>
> The end result, I hope, would be a keyword search for all keywords whose
> owner and category were those specified.
>
> Are you suggesting that I add a PathClass for each of the subclasses of
> CMSEntry then execute each query individually?  I'm hoping that there's
> a better solution than this, but if it works, I won't complain too much.
>
> I generally keep JDBC logging turned on so that I see all of the SQL as
> it goes by.  This leads me to believe that OJB would perform a query for
> each of the extent subclasses, even for a simple query:
>
> criteria.addEqualTo("ownerId", user.getId());
> query = QueryFactory.newQuery(Keyword.class, criteria);
>
> ..which works fine currently.
>
> I guess I just don't see why a regular extent query will work, but when
> joining against an extent class, it fails.
>
> Thank you for the info,
> Mark
>
> Jakob Braeuchi wrote:
> >
> > hi mark,
> >
> > > currently work.  I then found your related email.  It seems like a
> > > separate query for each extent-class table would be required for this
to
> > > work.
> > if the extents are in the pathExpression (ie. 'persons.name'  Person
with
> > subclasses) then it will not work at all because
> > 'persons' alwasy points to the super class Person.
> > but you could try to execute the query for each subclass and use hints
for
> > the pathExpression:
> >
> > addPathClass(String aPath, Class aClass) in Class QueryByCriteria
> >
> > ie: addPathClass("persons", PersonSubclass.class)
> >
> > hth
> > jakob
> >
> > ----- Original Message -----
> > From: "Mark Howell" <[EMAIL PROTECTED]>
> > To: "OJB Users List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 09, 2002 6:15 PM
> > Subject: Re: pathExpressions are NOT extent aware
> >
> > > Hello Jakob,
> > >
> > > I am very interested in this feature.  I would like to be able to join
> > > on an abstract extent class (spanning multiple tables) someday.  I've
> > > only recently attempted this, and quickly found that it doesn't
> > > currently work.  I then found your related email.  It seems like a
> > > separate query for each extent-class table would be required for this
to
> > > work.
> > >
> > > Just my .02,
> > > Mark
> > >
> > > Jakob Braeuchi wrote:
> > > >
> > > > hi all,
> > > >
> > > > just for your information: pathExpressions are NOT yet extent aware.
> > > >
> > > > ie:
> > > > if querying for ProductGroup having Articles named "A%"
> > > > (allArticlesInGroup.articleName) the extent classes are not part of
the
> > > > query.
> > > >
> > > > this is true for ordinary queries and also for report queries.
> > > > the problem is even worse when the path expression points to an
abstract
> > > > class having no tables, then you'll get a NullPointerException in
the
> > sql.
> > > >
> > > > imo the soulution to this problem is not simple because it needs
> > additional
> > > > joins modificatons of the where-statement.
> > > > any ideas ???
> > > >
> > > > jakob
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> > > --
> > > To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> > >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to