Further to this... it seems that when there is more than one field
descriptor for a single attribute, the path expression algorithms return the
one with the *lowest* id number of all of them. So this mapping:
<field-descriptor column="cuboidweight_grain"
conversion="com.kiwiplan.measure.ojb.QuantityGrainMapping" id="1"
jdbc-type="BIGINT" name="cuboidWeight"/>
<field-descriptor column="cuboidweight_units"
conversion="com.kiwiplan.measure.ojb.QuantityUnitMapping" id="2"
jdbc-type="INTEGER" name="cuboidWeight"/>
<field-descriptor column="cuboidweight_amount"
conversion="com.kiwiplan.measure.ojb.QuantityAmountMapping" id="3"
jdbc-type="BIGINT" name="cuboidWeight"/>

Gives rise to the cuboidweight_grain descriptor being returned from the
ClassDescriptor.getFieldDescriptorByName() and ...ByPath().

G

> -----Original Message-----
> From: Thomas Mahler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 16 October 2002 7:03 p.m.
> To: OJB Users List
> Subject: Re: Clarification of path expressions vs criteria
> 
> 
> Hi Gareth
> 
> Gareth Cronin wrote:
> > OK... as I understand it, when I query by criteria 
> (PersistenceBroker), the
> > criteria objects are being converted directly into WHERE clauses 
> 
> No, the criteria are translated into SQL by first looking up 
> the mapping 
> data. If you have used addEqualto("myAttribute", "someValue") 
> OJB will 
> lookup the ClassDescriptor of the class in question and will 
> look for a 
> FieldDescriptor for the Attribute "myAttribute". OJB will use 
> the column 
> name declared in the repository. If the field-descriptor looks like:
> 
> <field-descriptor id="1"
>           name="myAttribute"
>           column="MY_COLUMN"
>           jdbc-type="VARCHAR"
> />
> 
> OJB will use "MY_COLUMN" in the WHERE clause ("WHERE 
> MY_COLUMN='someValue'")
> 
> IF OJB can not find a filed-descriptor for "myAttribute" it 
> will use it 
> as a column name directly: ("WHERE myAttribute='someValue'")
> 
> > and
> > therefore the left argument of the (for example) 
> addEqualTo() method is a
> > *column* name, not an attribute. Is this correct? 
> 
> As mentionend above: it can be both !
> 
> > It certainly seems to work
> > at the moment.
> 
> correct! but you can also use java attribute names in criteria 
> expressions. This is the recommended way, as an O/R tool is meant to 
> *hide* RDBMS details like table and column names from the application 
> programmer.
> 
> > 
> > Now I want to use path expressions, but the documentation 
> refers to the
> > syntax "relationshipname.attributename". Is "attributename" 
> an attribute
> > name, i.e. the name attribute-value on a field-descriptor, 
> or a column name?
> > 
> 
> Path expression are always referring to reference attributes of java 
> classes.
> the idea of path expressions is to use the mapping 
> information to build 
> join statements.
> OJB can only infer a JOIN statement correctly if there is a 
> reference-descriptor pointing to another persistent class 
> which also has 
> a class-descriptor.
> OJB cannnot infer JOIN statements if you use column names.
> 
> > The difficulties arise from complex mapping where field 
> conversion and
> > row-readers are being used to map one attribute across 
> several columns, as
> > per earlier postings I have made. If I can't use column 
> names, then how does
> > OJB know which field mapping to use in the where clause?
> 
> If it is not possible to use attribute names you can not use the 
> path-expression feature.
> In this case you must use QueryBySql.
> 
> cheers,
> Thomas
> 
> 
> > Thanks
> > 
> > Gareth.
> > 
> > ---------------------------------------------
> > Gareth Cronin
> > Analyst/Programmer
> > Kiwiplan NZ Ltd: http://www.kiwiplan.com
> > Ph (64 9) 2727622 x854
> > 
> > --
> > 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