> I vote for solution #1 suggested by Michael - keep two collections of cars
> - one (persistent) managed by Cayenne, another (transient) managed by your
> ParkingLot subclass.
This will work, but I will often need to move objects from my transient to
persistent list which complicates matters... I'm suggesting an option 4 that
I would like your feedback on. It uses less lines of code and doesn't go to far
in trying to "trick" the app.
It subclasses DataContext and implements a new commitChangesSafe() method.
It 1) removes any objects that implements the SaveDataObject interface and has
the getSave() flag set to false, 2) commits changes, 3) re-adds the earlier removed
objects.
What do you think? What are the chances of geting increased control of which
objects to skip in commitChanges in the future? This would also be neat:
commitChanges(Class saveObjectsOfClass)
/Elia
public class SafeDataContext extends DataContext{
public void commitChangesSafe(){
// get all objects and iterate them
List objects = getObjectStore().getObjects();
List skipobjects = new List();
Iterator itr = objects.iterator();
DataObject obj;
while(itr.hasNext()){
obj= (DataObject ) itr.next();
// examine if object should be skipped thru the SaveDataObject interface
if (obj instanceof SaveDataObject){
if(! (obj (SaveDataObject)).getSave() ){
skipobjects.add(obj);
}
}
}
// remove objects from DataContext
unregisterObjects(skipobjects);
// commit changes
commitChanges();
// re-add objects to DataContext
itr = skipobjects.iterator();
while(itr.hasNext()){
obj= (DataObject ) itr.next();
registerNewObject(obj);
}
}
}
----- Original Message -----
From: "Andrus Adamchik" <andru..bjectstyle.org>
To: <cayenne-use..bjectstyle.org>
Sent: Wednesday, June 30, 2004 7:29 PM
Subject: RE: Working with Transient Objects
> My 2 cents... Expanding on Michaels solution...
>
> I vote for solution #1 suggested by Michael - keep two collections of cars
> - one (persistent) managed by Cayenne, another (transient) managed by your
> ParkingLot subclass. Your ParkingLot and Car classes become "decorators",
> amking the rest of the app unaware of the differences, and still keeping
> consistent object graph for Cayenne purposes (as Cayenne uses
> "read/writeProperty").
>
> This is a very clean option IMO. If you have problems with it, I suspect
> it has something to do with your implementation, and they are likely easy
> to fix. I think other suggested solutions may have varios undesired
> consequences.
>
> Use Jakarta commons-collections to help with list decorators.. E.g.
>
> 1. getCars() - override in subclass to do ListUtils.union(super.getCars(),
> transientCars)
>
> 2. addCar() - override in subclass to do "if car is transient add to
> transient cars and set car's parking lot, else call super)... you may need
> to override car.setParkingLot to use the similar logic...
>
> 3. removeCar() - override applying the same logic as add...
>
> Andrus
>
>
> > 1) Use transient variables like I suggested. Just keep the persistent
> > cars separate from the random cars. The persistent cars are obviously
> > in a data context, the random ones created outside of one (this might
> > not be possible, but I'd hope so).
> >
> > public List allCars()
> > {
> > List results = new List();
> >
> > results.addAll(savedCars());
> > results.addAll(randomCars());
> >
> > return results;
> > }
> >
> > (Add all the other plumbing you need to create the random cars, etc.)
>
>
>
>
This archive was generated by hypermail 2.0.0 : Wed Jun 30 2004 - 19:56:30 EDT