I had a similar situation.
I persist ScheduledPayments in the database.
I also have transient "Pay immediately" payments that contain almost the
same info but aren't stored as such in the database.
My solution was to create a Payment interface.
The interface contains all of the common functionality between the
ScheduledPayment and transient payment (pretty much everything).
Both my cayenne ScheduledPayment and my transient SimplePayment class
implement this interface.
The one downside is that they both cannot inherit from a common superclass.
I dealt with this by creating a PaymentHelper class that contains all of the
shared code used between both classes.
Then I simply do things like this:
public Date getNextDateToPay(Calendar todayReferenceCalendar, Calendar
todaysBatchEventCalendar, Date currentDueDate)
{
return PaymentHelper.getNextDateToPay(this, todayReferenceCalendar,
todaysBatchEventCalendar, currentDueDate);
}
You mentioned that you sometimes need to change an object from transient to
persistent.
I simply recreate whichever objecttype I need:
public SimplePayment(ScheduledPayment aScheduledPayment)
{
// recreate object
}
Obviously the one downside for this is that you would then have to update
any pointers to the new object. This wasn't a concern for my usage pattern.
If it were, I'd probably handle this using a delegation pattern, delegating
out the storage of the data to either a Cayenne-based object or a Map-backed
object depending on the need, and replacing my Payment interface with a
Payment concrete instance.
But the bottom line is that cayenne is used to represent persistent objects.
If the object isn't persistent, you shouldn't be trying to use Cayenne to
store it.
-Mike
This archive was generated by hypermail 2.0.0 : Thu Jul 01 2004 - 16:47:42 EDT