Re: What's a good way to handle orders?
Re: What's a good way to handle orders?
- Subject: Re: What's a good way to handle orders?
- From: Kevin Windham <email@hidden>
- Date: Sun, 6 Jan 2008 20:38:59 -0600
On Jan 6, 2008, at 5:31 PM, David LeBer wrote:
On 6-Jan-08, at 6:10 PM, Kevin Windham wrote:
I have an app that will take orders. I didn't fully consider the
consequences of inserting the orders directly into the DB. Now
I've run into the situation where an order gets created and then
someone decides to simply close their browser before completing
payment. Now I have a "bad" order in the system.
My initial thought for dealing with this was simply to not insert
the order and associated lineitems into the db context until after
the process is complete. The problem with this is that it violates
one of the rules I've read about. That is, that you should insert
objects into the context before any manipulation of those objects.
Inserting objects into an EOEditingContext does not save them to
the DB. That only happens when you call saveChanges on the EC.
So what is the problem with creating the order and lineItems and
only calling saveChanges on the EC when it is complete?
If the user walks away, the EC gets GCd and no order is entered in
the DB.
My initial thought was basically like yours. If they don't complete
the order then it will go away by itself, but it didn't quite work
out that way.
The way I understand it, the order may not be in the DB, but it does
interact with the other objects that are since it is part of the
object graph in memory. One case I saw was looking at order history.
The order wasn't in the DB, but when you go look at the order history
you can see the bogus order there. There are other things that might
be affected, the problem for me with going that route is I don't know
how exactly it works under the hood. I'm just worried there would be
other side effects that I don't know about.
Kevin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden