db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clóvis Wichoski <clovis_wicho...@uol.com.br>
Subject Re: OQL grammar changes
Date Thu, 01 Jul 2004 20:44:42 GMT

Thomas Dudziak wrote:

> Clóvis Wichoski wrote:
>
>>
>> The only working is if qtyFromClass == 1 (only one class in from 
>> clause) the else is for multiple classes and this TODO is because I 
>> don't know (for while) how OJB query selects or if it support 
>> multiple classes, I just started using OJB one week ago, I'm attempt 
>> to migrate from a production Castor application with minor changes on 
>> current source code, then one of requisites is that from classes as 
>> an alias, and supports uppercases on keywords, then the multiple 
>> classes come in like a bonus startup, when we had time this can be 
>> done or maybe not, I put the TODO to cause a thoughts about that.
>
>
> There are two somewhat different areas where queries are used in OJB: 
> for object retrieval, and for reporting. With the former you retrieve 
> persistent objects (i.e. instances of classes that have a class 
> descriptor) that match some criteria. The latter is to gather 
> information from the database, but the information is not required to 
> be a persistent object.
> For object retrieval IMO it would only make sense to have multiple 
> classes in the from clause when trying to limit the classes that are 
> searched in. E.g. if you have classes A, B, C, D with B, C, and D 
> extending from the abstract base class A, then a "select * from B, D" 
> would retrieve only instances from B and D and the where clause could 
> only specify features of the common basetype A.
> For report queries, the specification of multiple classes looks a lot 
> like a inner join specification but I don't know whether that is 
> feasable.

I agree, with this too.

>
> Could you perhaps provide some samples where you use multiple classes 
> in order to illustrate the concepts ?

for object retrieval we can use the follow ideia, Think in Collections 
of Objects that the referenced objects can't had no one interface or 
superclass in common, (think in a Vector with Person, Article, Build, 
Invoice ) then only solution for this is to had a single field point to 
OID for that objects and on a secondary call load this objects, 
programatically or in future can be done by an OQL like this:

SELECT car FROM myproject.Invoice invoice, myproject.Car car WHERE 
invoice.myItem.myObjectOid = car.oid AND invoice.date BETWEEN 
"2004-05-01" AND "2004-05-31"

or better to return only invoices for Cars

SELECT invoice FROM myproject.Invoice invoice, myproject.Car car WHERE 
invoice.myItem.myObjectOid = car.oid AND invoice.date BETWEEN 
"2004-05-01" AND "2004-05-31"

myObjectOid is only a field that maintains the OID for car, on the WHERE 
we put the JOIN,

this maybe used too, when we need return a referenced object but don't 
need the referer to know all about this reference. (note lazy don't 
apply here because if I need to serialize the Invoice but don't need to 
send whole car object, but we know that for this problem as many ways to 
solve).

but the reality here I usually load objects needed in a second call. for 
fields that only points to OID here are called Indirect Reference.

Hope this clarify

Clóvis


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message