Oops, I realized I should be adding some failure to the validateForSave()
method. Perhaps that would do the trick?
Elia
----- Original Message -----
From: "Elia Morling" <eli..amiljen.se>
To: <cayenne-use..bjectstyle.org>
Sent: Wednesday, June 30, 2004 7:51 PM
Subject: Re: Working with Transient Objects
> Ok, before I run down this route, which will be costly, I would like to throw out some
> other ideas. Would any of the below work? Thanks, Elia
>
> -------------------------------------------------
> 1) Override the get and set of persistantState in subclass
> -------------------------------------------------
>
> private boolean dontSave = false;
>
> public int getPersistenceState() {
> if(!dontSave){return PersistenceState.TRANSIENT}
> return persistenceState;
> }
>
> public void setPersistenceState(int persistenceState) {
> if(!dontSave){return;}
> super.setPersistenceState(persistenceState);
> }
>
> -------------------------------------------------
> 2) Override validateForSave in subclass
> -------------------------------------------------
> protected void validateForSave(ValidationResult validationResult) {
> if(!dontSave){return;}
> super.validateForSave(validationResult);
> }
>
>
> ----- 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 - 13:59:55 EDT