You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Derek Stevenson <de...@retrocode.com> on 2002/08/20 19:59:58 UTC
RE: trying to delete data from db - doSelect shows cached data
in stead
It seems using a combination of setNew() and using the alternate
getUserAttributes(Criteria criteria) (instead of calling the no-param
getUserAttributes() ) forces MochaUser to update its cached Vector of
UserAttributes.
I *think* it's working now, I'll keep my fingers crossed. If anyone out
there involved in developing the torque framework is listening, here's a
suggestion to address this. If you have table A/object A with a collection
of objects B (foreign key relationship between B and A), torque will
generate BaseA.addB(B b) methods. Could you perhaps add an autogenerated
BaseA.removeB(B b) method as well, which would take care of updating the
cache in object A and properly persist the deletion to the database? What
do people think?
Derek
At 05:35 AM 8/20/2002, you wrote:
>Derek,
>
>I think doing the setNew() true then false might do what you want (I seem to
>recall in the source of generated objects seeing that in various places, and
>wondering why it was done).
>
>In most of my apps, I am not deleting data, but in the one or two places
>where I do, I have done something like delete the related objects from a,
>then do a = APeer.retrieveByPK() or APeer.doSelect(criteria) and just
>reselect from the database. Not a great solution, because I end up re
>selecting my data out of the DB again, but does get a fresh copy!
>
>Eric
>
>-----Original Message-----
>From: Derek Stevenson [mailto:derek@retrocode.com]
>Sent: Monday, August 19, 2002 6:24 PM
>To: Turbine Users List
>Subject: RE: trying to delete data from db - doSelect shows cached data
>instead
>
>
>Thanks for the help, Eric.
>
>I understand the issue; however, how do you do a fresh select on object
>A? Looking at the source of BaseMochaUser (in this case):
>
> /**
> * Collection to store aggregation of collUserAttributes
> */
> protected Vector collUserAttributes;
>...
> public void addUserAttribute(UserAttribute l) throws Exception
> {
> getUserAttributes().add(l);
> l.setMochaUser((MochaUser)this);
> }
>...
> public Vector getUserAttributes() throws Exception
> {
> if (collUserAttributes == null)
> {
> collUserAttributes = getUserAttributes(new Criteria(10));
> }
> return collUserAttributes;
> }
>...
> public Vector getUserAttributes(Criteria criteria) throws Exception
> {
> if (collUserAttributes == null)
> {
> if ( isNew() )
> {
> collUserAttributes = new Vector();
> }
> else
> {
> criteria.add(UserAttributePeer.USER_ID, getUserId() );
> collUserAttributes =
>UserAttributePeer.doSelect(criteria);
> }
> }
> else
> {
> // criteria has no effect for a new object
> if ( !isNew() )
> {
> // the following code is to determine if a new query is
> // called for. If the criteria is the same as the last
> // one, just return the collection.
> criteria.add(UserAttributePeer.USER_ID, getUserId() );
> if ( !lastUserAttributesCriteria.equals(criteria) )
> {
> collUserAttributes =
>UserAttributePeer.doSelect(criteria);
> }
> }
> }
> lastUserAttributesCriteria = criteria;
> return collUserAttributes;
> }
>...
>
>Based on this, the getUserAttributes() method only returns a fresh select
>from the db when collUserAttributes is null; does collUserAttributes need
>to be set to null? That seems risky, since I don't know what else that
>might muss with in the class. Is there another way to force a fresh
>select? Do I need to somehow use the BaseObject.setNew() in combination
>with calling getUserAttributes(new Criteria()) instead of
>getUserAttributes() (the former seems to *maybe* force a fresh select if
>isNew() returns true)?
>
>Would it be better to instead use getUserAttributes() to get the vector,
>then delete the UserAttribute from the vector instead of deleting the
>UserAttribute directly from the database?
>
>This seems like a fairly standard operation, other folks must have run up
>against this and have suggestions for how to do this properly...
>
>Thoughts?
>
>Derek
>
>At 01:07 PM 8/19/2002, you wrote:
> >When you delete data, it doesn't deleted from the existing java objects.
>So
> >if object A has a collection of objects B, and you delete a member of the
> >collection B, then you need to do a fresh select on object A. Take a look
> >at the torque generated base objects and you will see the issues...
> >
> >Eric
> >
> >-----Original Message-----
> >From: Derek Stevenson [mailto:derek@retrocode.com]
> >Sent: Monday, August 19, 2002 3:31 PM
> >To: Turbine Users List
> >Subject: trying to delete data from db - doSelect shows cached data
> >instead
> >
> >
> >I've got the following tables defined in my torque xml:
> >
> > <table name="MOCHA_USER" idMethod="none">
> > <column name="USER_ID" required="true" primaryKey="true"
> >type="INTEGER"/>
> > </table>
> >
> > <table name="USER_ATTRIBUTE_CODE">
> > <column name="UA_CODE" required="true" primaryKey="true"
> >type="VARCHAR" size="8"/>
> > <column name="UA_DESC" type="VARCHAR" size="255"/>
> > </table>
> >
> > <table name="USER_ATTRIBUTE">
> > <column name="USER_ID" required="true" primaryKey="true"
> >type="INTEGER"/>
> > <column name="UA_CODE" required="true" primaryKey="true"
> >type="VARCHAR" size="8"/>
> > <column name="VALUE" type="VARCHAR" size="255"/>
> >
> > <foreign-key foreignTable="MOCHA_USER">
> > <reference local="USER_ID" foreign="USER_ID"/>
> > </foreign-key>
> > <foreign-key foreignTable="USER_ATTRIBUTE_CODE">
> > <reference local="UA_CODE" foreign="UA_CODE"/>
> > </foreign-key>
> > </table>
> >
> >
> >I want to add a new user attribute to the USER_ATTRIBUTE table, but before
> >doing so, I want to make sure all existing attributes of a particular class
> >are deleted first. For each of those attributes, I do the delete with the
> >following method (in my torque-generated MochaUser object):
> >
> > public void clearUserFlag(String flagName) throws Exception {
> > if (flagName != null || flagName.length() == 0) {
> > Criteria crit = new Criteria();
> > int userid = this.getUserId().getBigDecimal().intValue();
> > crit.add(UserAttributePeer.USER_ID, userid);
> > crit.add(UserAttributePeer.UA_CODE, flagName);
> > UserAttributePeer.doDelete(crit);
> > this.save();
> > }
> > }
> >
> >Then, I add the appropriate attribute via the MochaUser.addUserAttribute()
> >method, thus:
> >
> > public void addUserFlag(String flagName, String flagValue) throws
> >Exception {
> > // Add user attribute
> > UserAttribute ua = new UserAttribute();
> > ua.setUaCode(flagName);
> > if (flagValue == null || flagValue == "") {
> > flagValue = "true";
> > }
> > ua.setValue(flagValue);
> > this.addUserAttribute(ua);
> > ua.save();
> > }
> >
> >However, when I iterate through the Vector from
> >MochaUser.getUserAttributes(), I get both the deleted user attributes and
> >the newly added one! When I check the database, though, the deleted user
> >attribute is in fact gone. So, here's my questions:
> >
> >1. The getUserAttributes() method must be accessing some sort of cache of
> >the attributes (from the source it looks like there's a Vector that's
> >stored in memory to avoid db hits), and is returning the list of attributes
> >initially provided by the database, plus whatever's been added via the
> >addUserAttribute() method. Should I be doing the delete a different way,
> >that tells the MochaUser object to requery the database? Or alternatively
> >'notifies' MochaUser to delete the UserAttribute from its cached
>collection?
> >
> >2. I'm pretty sure the clearUserFlag method above isn't the most elegant
> >way to delete a user attribute. Any recommendations for modifying the
>code?
> >
> >TIA,
> >Derek
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
> >
> >--
> >To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> >For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>