Re: Why No Cascading Delete AT All...

[Thomas Mahler <th...@web.de>]

Hi Onno,

as you can see from the executed SQL:
"DELETE FROM vacancies WHERE v_id =  ?"
the query is simply translated into a SQL delete statement not caring 
about *any* auto-delete="true" settings!

You have to use broker.delete(aVacancy) to remove the Vacancy instance 
and all associated things!
Maybe this should be made clearer in the docu...

cheers,
Thomas


onno wrote:
> Hiya posted this earlier but no replies maybe due to lack of information,
> but we can't figure it out at all:
> 
> //A User Class
> <class-descriptor class="x.User" table="users" >
>     <field-descriptor autoincrement="true" column="u_id" id="1"
> jdbc-type="INTEGER" name="id" primarykey="true" />
>     <field-descriptor column="u_firstname" id="2" jdbc-type="VARCHAR" />
> </class-descriptor>
> 
> //Some Class Using this User
> <class-descriptor class="x.Vacancy" table="vacancies" >
>      <field-descriptor autoincrement="true" column="v_id" id="1"
> jdbc-type="INTEGER" name="id" primarykey="true" />
>      <field-descriptor name="userId" column="v_userId" id="2"
> jdbc-type="INTEGER" />
>      <reference-descriptor name="user"  class-ref="x.User"
> auto-retrieve="true" auto-update="true" auto-delete="true">
>         <foreignkey field-id-ref="2"/>
>     </reference-descriptor>
> </class-descriptor>
> 
> yet if we do
> 
> (from a retrieved (succesfully) Vacancy)
> 
> Criteria criteria = new Criteria();
> criteria.addEqualTo("id", new Integer(aVacancy.getId()));
> Query aQuery = new QueryByCriteria(x.Vacancy, criteria); //
> mBroker.deleteByQuery(aQuery); //
> 
> 765 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.ConnectionManagerImpl  - Try to change
> autoCommit state to 'false'
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.singlevm.PersistenceBrokerImpl  - deleteByQuery
> x.Vacancy, Query from class x.Vacancy where
> org.apache.ojb.broker.query.Criteria@9d22fc
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl  - executeDelete (by Query)
> : Query from class x.Vacancy where
> org.apache.ojb.broker.query.Criteria@9d22fc
> 67937 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl  - SQL: DELETE
> FROM vacancies WHERE v_id =  ?
> 68125 [AWT-EventQueue-0] DEBUG
> org.apache.ojb.broker.accesslayer.StatementManager  - closeResources was
> called
> 
> hence it deletes the Vacancy Succesfully yet the User (whose foreignkey is
> correct in the database) doesn't get deleted even with everything set to
> auto-x = "true"
> 
> we tried several mBroker.delete attempts but none did a cascading delete
> 
> we are at a loss.
> 
> Onno.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 

Re: Why No Cascading Delete AT All...

[onno <on...@onnos.com>]

Yo Thomas!

> as you can see from the executed SQL:
> "DELETE FROM vacancies WHERE v_id =  ?"
> the query is simply translated into a SQL delete statement not caring
> about *any* auto-delete="true" settings!

Indeed - this had me 'flustered' :)

> You have to use broker.delete(aVacancy) to remove the Vacancy instance
> and all associated things!

This fixed it - luckily we have 1 central place (which wraps OJB) so it was
an easy fix :) ...

> Maybe this should be made clearer in the docu...

Yes :) Coz there is no distinction in the docs about delete or deleteByQuery
(there reason we used deleteByQuery - is for mass deletes - it seemed a bit
silly to first retrieve all of them just before finishing them off - ie only
the 'linked' fields should be used, not so much the actual data) I figured
that using deleteByQuery OJB would take care of that 'nasty' business :)

Once again for clearing it up - our database got very big too quick :)

Onno