You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Clóvis Wichoski <cl...@uol.com.br> on 2004/06/28 22:47:12 UTC
OQL grammar changes
Hi devs,
I'm migrating from Castor, then here we use OQLs like this
select obj from myapp.Person obj where name="Joseph"
but on OJB this isn't supported, then in past I created a wrapper of OQL
for TopLink and created my own grammar based on oql-ojb.g
that supports the follow syntax:
select obj.name NAME, obj.rule RULE from myapp.Person obj
select obj from myapp.Person obj where name="Joseph"
select obj from myapp.Person
This includes support for Castor like OQLs, works with current ojb OQLs,
and starts OQL to returns Fields from ReportQuery,
I think that this is usefull for the OJB OQL support, then my question
is I need to change oql-ojb.g and sends the diffs, to contribute, or
send my changed oql.g to you for explore, and patch?
TIA
Clóvis
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
Clóvis Wichoski wrote:
> 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.
If I'm not mistaken, its the OQL equivalent of SQL joins, which is a
quite a bit more involving. But you're right, it is necessary for full
OQL3 compatibility.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Clóvis Wichoski <cl...@uol.com.br>.
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
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
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.
Could you perhaps provide some samples where you use multiple classes in
order to illustrate the concepts ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Clóvis Wichoski <cl...@uol.com.br>.
Thomas Dudziak wrote:
> Clóvis Wichoski wrote:
>
>> Hi,
>>
>> I will work on this and see what I can do...
>>
>> but before I need to ask some questions for Thomas or any other
>> commiters,
>> the OJB as a plan of what need or rules to be implemented in OQL?
>> the patchs that I send will be commited when? on checked if trusted,
>> one week, months, next version?
>
>
> I already planned to work on the OQL grammar (don't know why Jakob
> asked you too, we had the exact same topic a couple of weeks ago), to
> be more precise on two areas:
>
> - extraction of the embedded code into a separate class
> - addition of the missing OQL 3 features, mostly generic method
> support (methods names shouldn't be hardcoded in the grammar but
> rather resolved during creation of the query object) and missing
> operators
>
> I wanted to add your patch during the weekend. However, I have one
> question for you in return. You enhanced the from clause to support
> multiple classes. Is the implementation of this complete (I noticed a
> TODO) ?
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.
Regards
Clóvis
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas, clovis,
Thomas Dudziak wrote:
> Clóvis Wichoski wrote:
>
>> Hi,
>>
>> I will work on this and see what I can do...
>>
>> but before I need to ask some questions for Thomas or any other
>> commiters,
>> the OJB as a plan of what need or rules to be implemented in OQL?
>> the patchs that I send will be commited when? on checked if trusted,
>> one week, months, next version?
>
>
> I already planned to work on the OQL grammar (don't know why Jakob asked
> you too, we had the exact same topic a couple of weeks ago), to be more
i simply forgot.
jakob
> precise on two areas:
>
> - extraction of the embedded code into a separate class
> - addition of the missing OQL 3 features, mostly generic method support
> (methods names shouldn't be hardcoded in the grammar but rather resolved
> during creation of the query object) and missing operators
>
> I wanted to add your patch during the weekend. However, I have one
> question for you in return. You enhanced the from clause to support
> multiple classes. Is the implementation of this complete (I noticed a
> TODO) ?
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
Clóvis Wichoski wrote:
> Hi,
>
> I will work on this and see what I can do...
>
> but before I need to ask some questions for Thomas or any other commiters,
> the OJB as a plan of what need or rules to be implemented in OQL?
> the patchs that I send will be commited when? on checked if trusted, one
> week, months, next version?
I already planned to work on the OQL grammar (don't know why Jakob asked
you too, we had the exact same topic a couple of weeks ago), to be more
precise on two areas:
- extraction of the embedded code into a separate class
- addition of the missing OQL 3 features, mostly generic method support
(methods names shouldn't be hardcoded in the grammar but rather resolved
during creation of the query object) and missing operators
I wanted to add your patch during the weekend. However, I have one
question for you in return. You enhanced the from clause to support
multiple classes. Is the implementation of this complete (I noticed a
TODO) ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Clóvis Wichoski <cl...@uol.com.br>.
Hi,
I will work on this and see what I can do...
but before I need to ask some questions for Thomas or any other commiters,
the OJB as a plan of what need or rules to be implemented in OQL?
the patchs that I send will be commited when? on checked if trusted, one
week, months, next version?
Regards
Clóvis
Jakob Braeuchi wrote:
> hi clovis,
>
> are you the antlr guru i was waiting for ?
> if yes, please have a look at my old post:
>
> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
> Sent: Sun 10/12/2003 9:51 AM
> To: OJB Developers List
> Cc:
> Subject: Help: ANTLR guru needed !
>
>
>
> hi all,
>
> while playing with oql i realized that we do not support
> functions :( !
>
> OQLQuery query = odmg.newOQLQuery();
> query.create("select anArticle from " +
> Article.class.getName() +
> " where upper(articleName) like \"A%\" ");
>
>
> the upper-function in the where clause causes antlr errors:
>
> line 1: unexpected token: upper
> line 1: unexpected token: )
>
> i tried to fix it by adding ( and ) to the valid characters for
> Identifier. but breaks in and is_defined.
>
> after some hours of digging in oql-ojb.g i have to admit that i'm
> stuck.
> so please antlr-gurus have a look at it.
>
> jakob
>
>
>
> Clóvis Wichoski wrote:
>
>> Hi Thomas,
>>
>> I changed the ojb-oql.g to support case sensitive OQL reserved words
>> (SELECT,FROM,etc..) and to support alias and multiple class in FROM
>> clause, note that the support for multiple class is only for OQL
>> syntax, because the implementation of multiple class select must be a
>> more research.
>> Then now supported syntax OQL are:
>>
>> SELECT obj FROM myapp.Person
>> select obj from myapp.Person obj
>> select obj from myapp.Person obj, myapp.Person obj2
>>
>> Regards
>>
>> Clóvis
>>
>> follow are the diff:
>>
>> Index: src/java/org/apache/ojb/odmg/oql/oql-ojb.g
>> ===================================================================
>> RCS file:
>> /home/cvspublic/db-ojb/src/java/org/apache/ojb/odmg/oql/oql-ojb.g,v
>> retrieving revision 1.23
>> diff -r1.23 oql-ojb.g
>> 70,71c70,71
>> < * Modifications done by Ch. Rath & Th. Mahler & S. Harris
>> < *
>> ---
>> > * Modifications done by Ch. Rath & Th. Mahler & S. Harris & C.
>> Wichoski
>> > *
>> 94c94
>> < caseSensitiveLiterals=true;
>> ---
>> > caseSensitiveLiterals=false; //for compat with others OQL
>> 342a343
>> > Object[] classes = null;
>> 345a347,348
>> > boolean isAliasFrom = false;
>> > int qtyClassFrom = 0;
>> 363c366
>> < "from" clazz = fromClause
>> ---
>> > "from" classes = fromClause
>> 366c369
>> < if (clazz != null)
>> ---
>> > if (classes != null)
>> 368c371,373
>> < if (projectionAttrs[0].indexOf('.') < 0)
>> ---
>> > isAliasFrom =
>> ((Boolean)classes[classes.length-1]).booleanValue();
>> > qtyClassFrom = (classes.length-1) / ( isAliasFrom
>> ? 2 : 1);
>> > if (qtyClassFrom == 1)
>> 370c375,406
>> < query = QueryFactory.newQuery(clazz, criteria,
>> distinct);
>> ---
>> > clazz = (Class)classes[0];
>> > if (clazz != null)
>> > {
>> > if (projectionAttrs[0].indexOf('.') < 0)
>> > {
>> > query = QueryFactory.newQuery(clazz,
>> criteria, distinct);
>> > }
>> > else
>> > {
>> > ClassDescriptor cld =
>> MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
>> > for (int i = 0; i <
>> projectionAttrs.length; i++)
>> > {
>> > projectionAttrs[i] =
>> projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
>> > }
>> > > ArrayList descs =
>> cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
>> > int pathLen = descs.size();
>> > > if ((pathLen > 0) &&
>> (descs.get(pathLen - 1) instanceof ObjectReferenceDescriptor))
>> > {
>> > ObjectReferenceDescriptor ord =
>> >
>> ((ObjectReferenceDescriptor) descs.get(pathLen - 1));
>> > query =
>> QueryFactory.newQuery(clazz, criteria, distinct);
>> >
>> query.setObjectProjectionAttribute(projectionAttrs[0],
>> >
>> ord.getItemClass());
>> > }
>> > else
>> > {
>> > query =
>> QueryFactory.newReportQuery(clazz, projectionAttrs, criteria, distinct);
>> > }
>> > }
>> > }
>> 374,394c410,413
>> < ClassDescriptor cld =
>> MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
>> < for (int i = 0; i < projectionAttrs.length; i++)
>> < {
>> < projectionAttrs[i] =
>> projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
>> < }
>> <
>> < ArrayList descs =
>> cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
>> < int pathLen = descs.size();
>> <
>> < if ((pathLen > 0) && (descs.get(pathLen - 1)
>> instanceof ObjectReferenceDescriptor))
>> < {
>> < ObjectReferenceDescriptor ord =
>> < ((ObjectReferenceDescriptor)
>> descs.get(pathLen - 1));
>> < query = QueryFactory.newQuery(clazz,
>> criteria, distinct);
>> <
>> query.setObjectProjectionAttribute(projectionAttrs[0],
>> <
>> ord.getItemClass());
>> < }
>> < else
>> < {
>> < query = QueryFactory.newReportQuery(clazz,
>> projectionAttrs, criteria, distinct);
>> < }
>> ---
>> > /**
>> > * @TODO: make a Query from multiple class
>> maybe create a
>> > * SQL statement based on classes, or what?
>> > **/
>> 409a429
>> > Object[] classes = null;
>> 410a431,432
>> > boolean isAliasFrom = false;
>> > int qtyClassFrom = 0;
>> 418c440
>> < "in" clazz = fromClause
>> ---
>> > "in" classes = fromClause
>> 421,422c443,457
>> < if (clazz != null) {
>> < query = QueryFactory.newQuery(clazz, criteria);
>> ---
>> > isAliasFrom =
>> ((Boolean)classes[classes.length-1]).booleanValue();
>> > qtyClassFrom = (classes.length-1) / ( isAliasFrom ? 2
>> : 1);
>> > if (qtyClassFrom == 1)
>> > {
>> > clazz = (Class)classes[0];
>> > if (clazz != null) {
>> > query = QueryFactory.newQuery(clazz, criteria);
>> > }
>> > }
>> > else
>> > {
>> > /**
>> > * @TODO: make a Query from multiple class maybe
>> create a
>> > * SQL statement based on classes, or what?
>> > **/
>> 427,429c462
>> < fromClause returns [Class clazz = null] :
>> <
>> < id:Identifier
>> ---
>> > fromClause returns [Object[] classes = null] :
>> 431,433c464,551
>> < try {
>> < clazz = ClassHelper.getClass(id.getText());
>> < } catch (Exception e) {
>> ---
>> > Class firstClass = null;
>> > String firstLabel = null;
>> > Class clazz = null;
>> > String label = null;
>> > ArrayList list = null;
>> > Boolean isAlias = Boolean.FALSE;
>> > }
>> > > (
>> > id:Identifier
>> > (
>> > {
>> > try
>> > {
>> > firstClass =
>> ClassHelper.getClass(id.getText());
>> > } catch (Exception e) {
>> > }
>> > }
>> > )
>> > (
>> > lb:Identifier
>> > (
>> > {
>> > isAlias = Boolean.TRUE;
>> > firstLabel = lb.getText();
>> > }
>> > )
>> > )?
>> > > (
>> > TOK_COMMA
>> > id2:Identifier
>> > (
>> > {
>> > try
>> > {
>> > clazz =
>> ClassHelper.getClass(id2.getText());;
>> > } catch (Exception e) {
>> > }
>> > }
>> > )
>> > (
>> > lb2:Identifier
>> > (
>> > {
>> > label = lb2.getText();
>> > }
>> > )
>> > )?
>> > {
>> > //this because don't need create List for
>> single class FROM
>> > if (list == null)
>> > {
>> > list = new ArrayList();
>> > list.add(firstClass);
>> > if (firstLabel != null)
>> > {
>> > list.add(firstLabel);
>> > }
>> > }
>> > list.add(clazz);
>> > if (label != null)
>> > {
>> > list.add(label);
>> > }
>> > label = null;
>> > clazz = null;
>> > }
>> > )*
>> > )
>> > > {
>> > if (list == null)
>> > {
>> > //Te last position indicates if had or no Alias
>> > if (firstLabel == null)
>> > {
>> > classes = new Object[] {firstClass,isAlias};
>> > }
>> > else
>> > {
>> > classes = new Object[]
>> {firstClass,firstLabel,isAlias};
>> > }
>> > }
>> > else
>> > {
>> > list.add(isAlias);
>> > classes = (Object[]) list.toArray(new
>> Object[list.size()]);
>> 434a553
>> >
>>
>>
>> Thomas Dudziak wrote:
>>
>>> Clóvis Wichoski wrote:
>>>
>>>> Hi devs,
>>>>
>>>> I'm migrating from Castor, then here we use OQLs like this
>>>>
>>>> select obj from myapp.Person obj where name="Joseph"
>>>>
>>>> but on OJB this isn't supported, then in past I created a wrapper
>>>> of OQL for TopLink and created my own grammar based on oql-ojb.g
>>>> that supports the follow syntax:
>>>>
>>>> select obj.name NAME, obj.rule RULE from myapp.Person obj
>>>> select obj from myapp.Person obj where name="Joseph"
>>>> select obj from myapp.Person
>>>>
>>>> This includes support for Castor like OQLs, works with current ojb
>>>> OQLs, and starts OQL to returns Fields from ReportQuery,
>>>>
>>>> I think that this is usefull for the OJB OQL support, then my
>>>> question is I need to change oql-ojb.g and sends the diffs, to
>>>> contribute, or send my changed oql.g to you for explore, and patch?
>>>
>>>
>>>
>>>
>>> Yes, please send the diff. We were planning to have a look at the
>>> OQL grammar anyway in the not-so-far future, as some things are
>>> missing yet.
>>>
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi clovis,
are you the antlr guru i was waiting for ?
if yes, please have a look at my old post:
-----Original Message-----
From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
Sent: Sun 10/12/2003 9:51 AM
To: OJB Developers List
Cc:
Subject: Help: ANTLR guru needed !
hi all,
while playing with oql i realized that we do not support functions :( !
OQLQuery query = odmg.newOQLQuery();
query.create("select anArticle from " +
Article.class.getName() +
" where upper(articleName) like \"A%\" ");
the upper-function in the where clause causes antlr errors:
line 1: unexpected token: upper
line 1: unexpected token: )
i tried to fix it by adding ( and ) to the valid characters for
Identifier. but breaks in and is_defined.
after some hours of digging in oql-ojb.g i have to admit that i'm stuck.
so please antlr-gurus have a look at it.
jakob
Clóvis Wichoski wrote:
> Hi Thomas,
>
> I changed the ojb-oql.g to support case sensitive OQL reserved words
> (SELECT,FROM,etc..) and to support alias and multiple class in FROM
> clause, note that the support for multiple class is only for OQL syntax,
> because the implementation of multiple class select must be a more
> research.
> Then now supported syntax OQL are:
>
> SELECT obj FROM myapp.Person
> select obj from myapp.Person obj
> select obj from myapp.Person obj, myapp.Person obj2
>
> Regards
>
> Clóvis
>
> follow are the diff:
>
> Index: src/java/org/apache/ojb/odmg/oql/oql-ojb.g
> ===================================================================
> RCS file:
> /home/cvspublic/db-ojb/src/java/org/apache/ojb/odmg/oql/oql-ojb.g,v
> retrieving revision 1.23
> diff -r1.23 oql-ojb.g
> 70,71c70,71
> < * Modifications done by Ch. Rath & Th. Mahler & S. Harris
> < *
> ---
> > * Modifications done by Ch. Rath & Th. Mahler & S. Harris & C. Wichoski
> > *
> 94c94
> < caseSensitiveLiterals=true;
> ---
> > caseSensitiveLiterals=false; //for compat with others OQL
> 342a343
> > Object[] classes = null;
> 345a347,348
> > boolean isAliasFrom = false;
> > int qtyClassFrom = 0;
> 363c366
> < "from" clazz = fromClause
> ---
> > "from" classes = fromClause
> 366c369
> < if (clazz != null)
> ---
> > if (classes != null)
> 368c371,373
> < if (projectionAttrs[0].indexOf('.') < 0)
> ---
> > isAliasFrom =
> ((Boolean)classes[classes.length-1]).booleanValue();
> > qtyClassFrom = (classes.length-1) / ( isAliasFrom ? 2
> : 1);
> > if (qtyClassFrom == 1)
> 370c375,406
> < query = QueryFactory.newQuery(clazz, criteria,
> distinct);
> ---
> > clazz = (Class)classes[0];
> > if (clazz != null)
> > {
> > if (projectionAttrs[0].indexOf('.') < 0)
> > {
> > query = QueryFactory.newQuery(clazz,
> criteria, distinct);
> > }
> > else
> > {
> > ClassDescriptor cld =
> MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
> > for (int i = 0; i <
> projectionAttrs.length; i++)
> > {
> > projectionAttrs[i] =
> projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
> > }
> > > ArrayList descs =
> cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
> > int pathLen = descs.size();
> > > if ((pathLen > 0) &&
> (descs.get(pathLen - 1) instanceof ObjectReferenceDescriptor))
> > {
> > ObjectReferenceDescriptor ord =
> > ((ObjectReferenceDescriptor)
> descs.get(pathLen - 1));
> > query = QueryFactory.newQuery(clazz,
> criteria, distinct);
> >
> query.setObjectProjectionAttribute(projectionAttrs[0],
> >
> ord.getItemClass());
> > }
> > else
> > {
> > query =
> QueryFactory.newReportQuery(clazz, projectionAttrs, criteria, distinct);
> > }
> > }
> > }
> 374,394c410,413
> < ClassDescriptor cld =
> MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
> < for (int i = 0; i < projectionAttrs.length; i++)
> < {
> < projectionAttrs[i] =
> projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
> < }
> <
> < ArrayList descs =
> cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
> < int pathLen = descs.size();
> <
> < if ((pathLen > 0) && (descs.get(pathLen - 1)
> instanceof ObjectReferenceDescriptor))
> < {
> < ObjectReferenceDescriptor ord =
> < ((ObjectReferenceDescriptor)
> descs.get(pathLen - 1));
> < query = QueryFactory.newQuery(clazz, criteria,
> distinct);
> <
> query.setObjectProjectionAttribute(projectionAttrs[0],
> <
> ord.getItemClass());
> < }
> < else
> < {
> < query = QueryFactory.newReportQuery(clazz,
> projectionAttrs, criteria, distinct);
> < }
> ---
> > /**
> > * @TODO: make a Query from multiple class maybe
> create a
> > * SQL statement based on classes, or what?
> > **/
> 409a429
> > Object[] classes = null;
> 410a431,432
> > boolean isAliasFrom = false;
> > int qtyClassFrom = 0;
> 418c440
> < "in" clazz = fromClause
> ---
> > "in" classes = fromClause
> 421,422c443,457
> < if (clazz != null) {
> < query = QueryFactory.newQuery(clazz, criteria);
> ---
> > isAliasFrom =
> ((Boolean)classes[classes.length-1]).booleanValue();
> > qtyClassFrom = (classes.length-1) / ( isAliasFrom ? 2 : 1);
> > if (qtyClassFrom == 1)
> > {
> > clazz = (Class)classes[0];
> > if (clazz != null) {
> > query = QueryFactory.newQuery(clazz, criteria);
> > }
> > }
> > else
> > {
> > /**
> > * @TODO: make a Query from multiple class maybe create a
> > * SQL statement based on classes, or what?
> > **/
> 427,429c462
> < fromClause returns [Class clazz = null] :
> <
> < id:Identifier
> ---
> > fromClause returns [Object[] classes = null] :
> 431,433c464,551
> < try {
> < clazz = ClassHelper.getClass(id.getText());
> < } catch (Exception e) {
> ---
> > Class firstClass = null;
> > String firstLabel = null;
> > Class clazz = null;
> > String label = null;
> > ArrayList list = null;
> > Boolean isAlias = Boolean.FALSE;
> > }
> > > (
> > id:Identifier
> > (
> > {
> > try
> > {
> > firstClass = ClassHelper.getClass(id.getText());
> > } catch (Exception e) {
> > }
> > }
> > )
> > (
> > lb:Identifier
> > (
> > {
> > isAlias = Boolean.TRUE;
> > firstLabel = lb.getText();
> > }
> > )
> > )?
> > > (
> > TOK_COMMA
> > id2:Identifier
> > (
> > {
> > try
> > {
> > clazz =
> ClassHelper.getClass(id2.getText());;
> > } catch (Exception e) {
> > }
> > }
> > )
> > (
> > lb2:Identifier
> > (
> > {
> > label = lb2.getText();
> > }
> > )
> > )?
> > {
> > //this because don't need create List for single
> class FROM
> > if (list == null)
> > {
> > list = new ArrayList();
> > list.add(firstClass);
> > if (firstLabel != null)
> > {
> > list.add(firstLabel);
> > }
> > }
> > list.add(clazz);
> > if (label != null)
> > {
> > list.add(label);
> > }
> > label = null;
> > clazz = null;
> > }
> > )*
> > )
> > > {
> > if (list == null)
> > {
> > //Te last position indicates if had or no Alias
> > if (firstLabel == null)
> > {
> > classes = new Object[] {firstClass,isAlias};
> > }
> > else
> > {
> > classes = new Object[]
> {firstClass,firstLabel,isAlias};
> > }
> > }
> > else
> > {
> > list.add(isAlias);
> > classes = (Object[]) list.toArray(new
> Object[list.size()]);
> 434a553
> >
>
>
>
> Thomas Dudziak wrote:
>
>> Clóvis Wichoski wrote:
>>
>>> Hi devs,
>>>
>>> I'm migrating from Castor, then here we use OQLs like this
>>>
>>> select obj from myapp.Person obj where name="Joseph"
>>>
>>> but on OJB this isn't supported, then in past I created a wrapper of
>>> OQL for TopLink and created my own grammar based on oql-ojb.g
>>> that supports the follow syntax:
>>>
>>> select obj.name NAME, obj.rule RULE from myapp.Person obj
>>> select obj from myapp.Person obj where name="Joseph"
>>> select obj from myapp.Person
>>>
>>> This includes support for Castor like OQLs, works with current ojb
>>> OQLs, and starts OQL to returns Fields from ReportQuery,
>>>
>>> I think that this is usefull for the OJB OQL support, then my
>>> question is I need to change oql-ojb.g and sends the diffs, to
>>> contribute, or send my changed oql.g to you for explore, and patch?
>>
>>
>>
>> Yes, please send the diff. We were planning to have a look at the OQL
>> grammar anyway in the not-so-far future, as some things are missing yet.
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
Clóvis Wichoski wrote:
> Yes, attached are the oql-ojb.g
Is in CVS.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Clóvis Wichoski <cl...@uol.com.br>.
Hi Thomas,
Yes, attached are the oql-ojb.g
Thomas Dudziak wrote:
> Clóvis Wichoski wrote:
>
>> Hi Thomas,
>>
>> I changed the ojb-oql.g to support case sensitive OQL reserved words
>> (SELECT,FROM,etc..) and to support alias and multiple class in FROM
>> clause, note that the support for multiple class is only for OQL
>> syntax, because the implementation of multiple class select must be a
>> more research.
>> Then now supported syntax OQL are:
>>
>> SELECT obj FROM myapp.Person
>> select obj from myapp.Person obj
>> select obj from myapp.Person obj, myapp.Person obj2
>
>
> I tried to apply your patch with Eclipse, but it didn't work because
> Eclipse needs an unified patch (yours was a patch in standard format).
> Could you create an unified patch, or send the patched oql-ojb.g ?
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
Clóvis Wichoski wrote:
> Hi Thomas,
>
> I changed the ojb-oql.g to support case sensitive OQL reserved words
> (SELECT,FROM,etc..) and to support alias and multiple class in FROM
> clause, note that the support for multiple class is only for OQL syntax,
> because the implementation of multiple class select must be a more
> research.
> Then now supported syntax OQL are:
>
> SELECT obj FROM myapp.Person
> select obj from myapp.Person obj
> select obj from myapp.Person obj, myapp.Person obj2
I tried to apply your patch with Eclipse, but it didn't work because
Eclipse needs an unified patch (yours was a patch in standard format).
Could you create an unified patch, or send the patched oql-ojb.g ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Clóvis Wichoski <cl...@uol.com.br>.
Hi Thomas,
I changed the ojb-oql.g to support case sensitive OQL reserved words
(SELECT,FROM,etc..) and to support alias and multiple class in FROM
clause, note that the support for multiple class is only for OQL syntax,
because the implementation of multiple class select must be a more research.
Then now supported syntax OQL are:
SELECT obj FROM myapp.Person
select obj from myapp.Person obj
select obj from myapp.Person obj, myapp.Person obj2
Regards
Clóvis
follow are the diff:
Index: src/java/org/apache/ojb/odmg/oql/oql-ojb.g
===================================================================
RCS file:
/home/cvspublic/db-ojb/src/java/org/apache/ojb/odmg/oql/oql-ojb.g,v
retrieving revision 1.23
diff -r1.23 oql-ojb.g
70,71c70,71
< * Modifications done by Ch. Rath & Th. Mahler & S. Harris
< *
---
> * Modifications done by Ch. Rath & Th. Mahler & S. Harris & C. Wichoski
> *
94c94
< caseSensitiveLiterals=true;
---
> caseSensitiveLiterals=false; //for compat with others OQL
342a343
> Object[] classes = null;
345a347,348
> boolean isAliasFrom = false;
> int qtyClassFrom = 0;
363c366
< "from" clazz = fromClause
---
> "from" classes = fromClause
366c369
< if (clazz != null)
---
> if (classes != null)
368c371,373
< if (projectionAttrs[0].indexOf('.') < 0)
---
> isAliasFrom =
((Boolean)classes[classes.length-1]).booleanValue();
> qtyClassFrom = (classes.length-1) / ( isAliasFrom ? 2
: 1);
> if (qtyClassFrom == 1)
370c375,406
< query = QueryFactory.newQuery(clazz, criteria,
distinct);
---
> clazz = (Class)classes[0];
> if (clazz != null)
> {
> if (projectionAttrs[0].indexOf('.') < 0)
> {
> query = QueryFactory.newQuery(clazz,
criteria, distinct);
> }
> else
> {
> ClassDescriptor cld =
MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
> for (int i = 0; i <
projectionAttrs.length; i++)
> {
> projectionAttrs[i] =
projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
> }
>
> ArrayList descs =
cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
> int pathLen = descs.size();
>
> if ((pathLen > 0) && (descs.get(pathLen -
1) instanceof ObjectReferenceDescriptor))
> {
> ObjectReferenceDescriptor ord =
> ((ObjectReferenceDescriptor)
descs.get(pathLen - 1));
> query = QueryFactory.newQuery(clazz,
criteria, distinct);
>
query.setObjectProjectionAttribute(projectionAttrs[0],
>
ord.getItemClass());
> }
> else
> {
> query =
QueryFactory.newReportQuery(clazz, projectionAttrs, criteria, distinct);
> }
> }
> }
374,394c410,413
< ClassDescriptor cld =
MetadataManager.getInstance().getRepository().getDescriptorFor(clazz);
< for (int i = 0; i < projectionAttrs.length; i++)
< {
< projectionAttrs[i] =
projectionAttrs[i].substring(projectionAttrs[i].indexOf('.') + 1);
< }
<
< ArrayList descs =
cld.getAttributeDescriptorsForPath(projectionAttrs[0]);
< int pathLen = descs.size();
<
< if ((pathLen > 0) && (descs.get(pathLen - 1)
instanceof ObjectReferenceDescriptor))
< {
< ObjectReferenceDescriptor ord =
< ((ObjectReferenceDescriptor)
descs.get(pathLen - 1));
< query = QueryFactory.newQuery(clazz, criteria,
distinct);
<
query.setObjectProjectionAttribute(projectionAttrs[0],
<
ord.getItemClass());
< }
< else
< {
< query = QueryFactory.newReportQuery(clazz,
projectionAttrs, criteria, distinct);
< }
---
> /**
> * @TODO: make a Query from multiple class maybe
create a
> * SQL statement based on classes, or what?
> **/
409a429
> Object[] classes = null;
410a431,432
> boolean isAliasFrom = false;
> int qtyClassFrom = 0;
418c440
< "in" clazz = fromClause
---
> "in" classes = fromClause
421,422c443,457
< if (clazz != null) {
< query = QueryFactory.newQuery(clazz, criteria);
---
> isAliasFrom =
((Boolean)classes[classes.length-1]).booleanValue();
> qtyClassFrom = (classes.length-1) / ( isAliasFrom ? 2 : 1);
> if (qtyClassFrom == 1)
> {
> clazz = (Class)classes[0];
> if (clazz != null) {
> query = QueryFactory.newQuery(clazz, criteria);
> }
> }
> else
> {
> /**
> * @TODO: make a Query from multiple class maybe create a
> * SQL statement based on classes, or what?
> **/
427,429c462
< fromClause returns [Class clazz = null] :
<
< id:Identifier
---
> fromClause returns [Object[] classes = null] :
431,433c464,551
< try {
< clazz = ClassHelper.getClass(id.getText());
< } catch (Exception e) {
---
> Class firstClass = null;
> String firstLabel = null;
> Class clazz = null;
> String label = null;
> ArrayList list = null;
> Boolean isAlias = Boolean.FALSE;
> }
>
> (
> id:Identifier
> (
> {
> try
> {
> firstClass = ClassHelper.getClass(id.getText());
> } catch (Exception e) {
> }
> }
> )
> (
> lb:Identifier
> (
> {
> isAlias = Boolean.TRUE;
> firstLabel = lb.getText();
> }
> )
> )?
>
> (
> TOK_COMMA
> id2:Identifier
> (
> {
> try
> {
> clazz = ClassHelper.getClass(id2.getText());;
> } catch (Exception e) {
> }
> }
> )
> (
> lb2:Identifier
> (
> {
> label = lb2.getText();
> }
> )
> )?
> {
> //this because don't need create List for single
class FROM
> if (list == null)
> {
> list = new ArrayList();
> list.add(firstClass);
> if (firstLabel != null)
> {
> list.add(firstLabel);
> }
> }
> list.add(clazz);
> if (label != null)
> {
> list.add(label);
> }
> label = null;
> clazz = null;
> }
> )*
> )
>
> {
> if (list == null)
> {
> //Te last position indicates if had or no Alias
> if (firstLabel == null)
> {
> classes = new Object[] {firstClass,isAlias};
> }
> else
> {
> classes = new Object[]
{firstClass,firstLabel,isAlias};
> }
> }
> else
> {
> list.add(isAlias);
> classes = (Object[]) list.toArray(new
Object[list.size()]);
434a553
>
Thomas Dudziak wrote:
> Clóvis Wichoski wrote:
>
>> Hi devs,
>>
>> I'm migrating from Castor, then here we use OQLs like this
>>
>> select obj from myapp.Person obj where name="Joseph"
>>
>> but on OJB this isn't supported, then in past I created a wrapper of
>> OQL for TopLink and created my own grammar based on oql-ojb.g
>> that supports the follow syntax:
>>
>> select obj.name NAME, obj.rule RULE from myapp.Person obj
>> select obj from myapp.Person obj where name="Joseph"
>> select obj from myapp.Person
>>
>> This includes support for Castor like OQLs, works with current ojb
>> OQLs, and starts OQL to returns Fields from ReportQuery,
>>
>> I think that this is usefull for the OJB OQL support, then my
>> question is I need to change oql-ojb.g and sends the diffs, to
>> contribute, or send my changed oql.g to you for explore, and patch?
>
>
> Yes, please send the diff. We were planning to have a look at the OQL
> grammar anyway in the not-so-far future, as some things are missing yet.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: OQL grammar changes
Posted by Thomas Dudziak <to...@first.fhg.de>.
Clóvis Wichoski wrote:
> Hi devs,
>
> I'm migrating from Castor, then here we use OQLs like this
>
> select obj from myapp.Person obj where name="Joseph"
>
> but on OJB this isn't supported, then in past I created a wrapper of OQL
> for TopLink and created my own grammar based on oql-ojb.g
> that supports the follow syntax:
>
> select obj.name NAME, obj.rule RULE from myapp.Person obj
> select obj from myapp.Person obj where name="Joseph"
> select obj from myapp.Person
>
> This includes support for Castor like OQLs, works with current ojb OQLs,
> and starts OQL to returns Fields from ReportQuery,
>
> I think that this is usefull for the OJB OQL support, then my question
> is I need to change oql-ojb.g and sends the diffs, to contribute, or
> send my changed oql.g to you for explore, and patch?
Yes, please send the diff. We were planning to have a look at the OQL
grammar anyway in the not-so-far future, as some things are missing yet.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org