I just tried what you suggested and it seems to work fine.
1.) I extended Criteria and use only my subclass to query extents
2.) I am using a QueryCustomizer to load only those references which have not been deleted.
But now I encounter some more difficulties when I am using decomposed relations.
I have a class Department. Departments can have subdeparments and I have an association-class DepartmentDepartment which store some information about the relationship.
For the sake of clearity say I have the following departments: A, B, C (deleted) and relations A->C, A->B
What I expect is, that when I access Department A it only has 1 departments (namely B) because C has been marked as deleted. But my (quite simple) query-customizer cannot handle this case. At the moment it is implemented like this:
public Query customizeQuery(
Object obj, PersistenceBroker pb, CollectionDescriptor cd,
Query q) {
Criteria res = new RespectDeletedCriteria();
Criteria org = q.getCriteria();
org.addAndCriteria(res);
return QueryFactory.newQuery(q.getBaseClass(), org);
}Do you have any suggestions how to handle this ?
Tino
Charles N. Harvey III wrote:
I don't think you can tell OJB to always use a certain Criteria object. From your example below, I would change it to this:
MyCriteria crit = new MyCriteria(); Query q = QueryFactory.newQuery( MyClass, crit ); Collection objects = pb.getCollectionByQuery( q );
As long as you always do "new MyCriteria()" instead of "new Criteria()" you should be fine. The only other thing I would suggest is to abstract the PersistenceBroker into a general use class so you don't have to instantiate it all the time.
---------------------------------------------------------------
public class MyRepository
{
public MyRepository getInstance()
{ return new MyRepository();
}
protected PersistenceBroker getPersistenceBroker()
{ PersistenceBroker broker = PersistenceBrokerFactory.createPersistenceBroker( this.pbKey );
return broker;
}
protected void releasePersistenceBroker( PersistenceBroker broker )
{ if( broker != null )
broker.close();
}
public Collection selectMyObjects( Class myClass )
throws OJBException
{ MyCriteria crit = new MyCriteria();
Query q = QueryFactory.newQuery( myClass, crit );
return selectObjects( q );
}
public Collection selectObjects( Query query )
throws OJBException
{ PersistenceBroker broker = null;
try
{ broker = this.getPersistenceBroker();
return broker.getCollectionByQuery( query );
}
catch( Throwable e )
{ throw new OJBException( e );
}
finally
{ this.releasePersistenceBroker( broker );
}
}
}
---------------------------------------------------------------
Then, your queries would be as simple as this:
MyRepository repo = MyRepository.getInstance(); Collection objects = repo.selectMyObjects( MyClass.class );
Well, that's how I do it anyway. You might not like that as much. But that
makes sure your queries are always the same, and I really like not having to fuss
about with the PersistenceBroker all the time.
Charlie
Tino Schöllhorn wrote:
Hi,
that sounds great. Is there a way to tell OJB that it always should use MyCriteria from the QueryFactory?
Or do I have to implement an own version of it?
Regards Tino
Charles N. Harvey III wrote:
Extend Criteria with a MyCriteria.
public class MyCriteria extends Criteria { public MyCriteria() { addDeletedEqualTo( true ); }
public addDeletedEqualTo( boolean bValue ) { this.addEqualTo( "deleted", bValue ); } }
Works for me. I usually create a Criteria object for each OJB Object that
I have. I add a bunch of convenience methods to add values to the criteria.
Charlie
Tino Schöllhorn wrote:
Hallo Daniel,
that sound great. But still I do have one question: how could you then load all non-deleted object *without* using the deleted-flag. I mean something like
Criteria crit = new Criteria();
// I can use any criteria here but I don't want to have to use "deleted"
....
Query q = QueryFactory.newQuery(MyClass, myCriteria);
Collection objects = pb.getCollectionByQuery(q);
// the result are all Objects which have the deleted-flag == false
Any suggestions?
regards Tino
Daniel Perry wrote:
I am using this in a complex app (due to idiot admin users deleting stuff
they shouldnt!). All objects have a boolean (mapped to int) "deleted". For
all queries i look for objects with deleted=false. For relationships, i
wrote a querycustomizer which adds deleted=false to collections. (see below
example)
It;s very simple and works a treat!
If you have a 'base' bean, which all other beans inherit, you can put the
'deleted' attribute there, and can use a delete method for deleting any
beans! (note: i dont use extents for this in the repository, just map it for
all beans)
<collection-descriptor name="subFamilies"
element-class-ref="com.netcase.pdp.bo.JobSubFamily" proxy="true">
<inverse-foreignkey field-ref="jobFamilyId"/>
<query-customizer
class="com.netcase.pdp.ojb.NestedElementCustomQuery">
<attribute attribute-name="equalsZeroField"
attribute-value="deleted"/>
<attribute attribute-name="orderField" attribute-value="name"/>
</query-customizer>
</collection-descriptor>
-----Original Message----- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 14:01 To: OJB Users List Subject: Re: soft-deleting objects
If you have a "deleted" style flag in the database for the soft delete
you can probably accomplish this via a query customizer. If you mean to
not flag the delete in the database at all, but only treat it as such
in the application -- that is a bit trickier, but can probably be done
via pb callbacks/row readers.
-Brian
On Mar 23, 2004, at 6:21 AM, Tino Schöllhorn wrote:
Hi,
I want to implement something like a soft-delete:
Objects should be marked as "deleted" in its corresponing table and
OJB should just ignore them when it is materializing or querying them.
Where would be the best point to start when I want to implement this
feature? I just played around with the RowReader-Concept - but I have
the feeling that this is not the right place to start, because I think
I have to modify the queries OJB is submitting to the database.
Any ideas?
Regards Tino
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
