You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Tino Schöllhorn <t....@tiscali.de> on 2004/03/23 12:21:03 UTC

soft-deleting objects

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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: repository.xml in a jar

Posted by Stefan Schlösser <ss...@intermediate.de>.
Hi,

we have similar Problems when copying data from one db to another.

You could use the same include mechanism ojb is using i.e. &user.xml to 
point to a "custom" xml in the file system. You'd just have to include 
an empty file with your code.

Otherwise you could also modify the ojb repository at run-time, there is 
  some kind of interface to it. You'd then just have your own property 
files to control the behaviour.

Cheers,
   Stefan


Charles N. Harvey III wrote:

> Hello.
> I am trying to build an interface to a particular database and package it
> all up in a jar.  Then have this jar included in other applications.  The
> thing is, I want to keep the OJB.properties and repository.xml inside the
> jar, since it does not change.  If the application that will house this
> jar has mappings of its own, how do I make OJB see both sets of 
> configurations?
> Is there way to do this?  Can I give repositoryFile multiple xml files:
> 
> #------------------------------------------------------------------------
> # repository file settings
> #------------------------------------------------------------------------
> # The repositoryFile entry tells OJB to use this file as as its standard
> # mapping repository. The file is looked up from the classpath.
> #
> repositoryFile = repository.xml, repository-ldap.xml
> #------------------------------------------------------------------------
> 
> Or, should I create a properties file with a different name, 
> OJB-LDAP.properties
> and then have that call repository-ldap.xml?  Then I would have to set a
> system property telling OJB where to find the new properties file, but
> wouldn't that then make OJB not see the original one?
> 
> Yes, my head is spinning over this one.  And I haven't even asked about the
> LDAP stuff yet.  ;)  Found a free jar on Novell that makes any LDAP server
> look like a relational database, so I can use OJB!!
> 
> Any tips are welcomed.  Thanks a lot.
> 
> 
> Charlie
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 



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


repository.xml in a jar

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Hello.
I am trying to build an interface to a particular database and package it
all up in a jar.  Then have this jar included in other applications.  The
thing is, I want to keep the OJB.properties and repository.xml inside the
jar, since it does not change.  If the application that will house this
jar has mappings of its own, how do I make OJB see both sets of 
configurations?
Is there way to do this?  Can I give repositoryFile multiple xml files:

#------------------------------------------------------------------------
# repository file settings
#------------------------------------------------------------------------
# The repositoryFile entry tells OJB to use this file as as its standard
# mapping repository. The file is looked up from the classpath.
#
repositoryFile = repository.xml, repository-ldap.xml
#------------------------------------------------------------------------

Or, should I create a properties file with a different name, 
OJB-LDAP.properties
and then have that call repository-ldap.xml?  Then I would have to set a
system property telling OJB where to find the new properties file, but
wouldn't that then make OJB not see the original one?

Yes, my head is spinning over this one.  And I haven't even asked about the
LDAP stuff yet.  ;)  Found a free jar on Novell that makes any LDAP server
look like a relational database, so I can use OJB!!

Any tips are welcomed.  Thanks a lot.


Charlie


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


Re: soft-deleting objects

Posted by Tino Schöllhorn <t....@tiscali.de>.
Hello Charles,

honestly I don't understand how this could help me as I don't have any 
subclassing in my use-case. As I understand the mapping you showed me is 
  for mapping class-hierarchies - which is definetely not what I want. 
But thank for your help anyway - I think I am on the right way now 
(using a custom Criteria and a QueryCustomizer).

Tino

Charles N. Harvey III wrote:

> Tino,
> Are your tables joined?  It sounds like they should be.  Like, 
> department_id
> is the foreign key in SUB_DEPARTMENT.  That's what it seems like the 
> setup is.
> If so, you should take a look at this:
> http://db.apache.org/ojb/tutorial3.html#Mapping%20Classes%20on%20Multiple%20Joined%20Tables 
> 
> 
> If your tables are setup this way, you can add criteria to your query based
> on either table.  So...
> 
> 
> Criteria crit = new MyCriteria();
> crit.addEqualTo( "department", "A" );  // adds "WHERE dept.department = 
> 'A'"
> crit.addEqualTo( "deleted", "false" ); // adds "WHERE sub.deleted = 
> 'false'"
> 
> 
> Take a look at the tutorial, its really helpful in describing better 
> ways to
> setup your data and how to query it.
> 
> 
> Charlie
> 
> 
> 
> Tino Schöllhorn wrote:
> 
>> Hi,
>>
>> 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:mccallister@forthillcompany.com]
>>>>>>> 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: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------- 
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>



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


Re: soft-deleting objects

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Tino,
Are your tables joined?  It sounds like they should be.  Like, department_id
is the foreign key in SUB_DEPARTMENT.  That's what it seems like the 
setup is.
If so, you should take a look at this:
http://db.apache.org/ojb/tutorial3.html#Mapping%20Classes%20on%20Multiple%20Joined%20Tables

If your tables are setup this way, you can add criteria to your query based
on either table.  So...


Criteria crit = new MyCriteria();
crit.addEqualTo( "department", "A" );  // adds "WHERE dept.department = 'A'"
crit.addEqualTo( "deleted", "false" ); // adds "WHERE sub.deleted = 'false'"


Take a look at the tutorial, its really helpful in describing better ways to
setup your data and how to query it.


Charlie



Tino Schöllhorn wrote:

> Hi,
>
> 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:mccallister@forthillcompany.com]
>>>>>> 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: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>

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


Re: soft-deleting objects

Posted by Tino Schöllhorn <t....@tiscali.de>.
Hi,

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:mccallister@forthillcompany.com]
>>>>> 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: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>



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


Re: soft-deleting objects

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
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:mccallister@forthillcompany.com]
>>>> 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: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>

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


Re: soft-deleting objects

Posted by Tino Schöllhorn <t....@tiscali.de>.
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:mccallister@forthillcompany.com]
>>> 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: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>



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


Re: soft-deleting objects

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
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:mccallister@forthillcompany.com]
>> 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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>

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


Re: soft-deleting objects

Posted by Tino Schöllhorn <t....@tiscali.de>.
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:mccallister@forthillcompany.com]
> 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: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org



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


RE: soft-deleting objects

Posted by Daniel Perry <d....@netcase.co.uk>.
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:mccallister@forthillcompany.com]
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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>



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



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


Re: soft-deleting objects

Posted by Brian McCallister <mc...@forthillcompany.com>.
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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>



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