persistence@glassfish.java.net

Re: Remove persistent object from collection: Best practice

From: Greg Ederer <greg_at_ergonosis.com>
Date: Wed, 08 Nov 2006 14:00:14 -0800
Hi Marina,

Marina Vatkina wrote:
Hi Greg,

I have a question: By the time the user has decided to
remove all cats, has the shopping cart contents been
committed to the database?
  
I didn't even realize that I need to think about that.  I think it would be safer to assume that the contents may not have been committed before a delete.  I'll definitely be thinking about this from now on.
If yes, a bulk delete can be an option (but again, it should
be done very carefully to avoid any conflicts with the
in-memory persistence context).
  
Sounds complicated.
If not, it won't find anything to remove anyway, and I would
think that your original solution is a better way to do it.
In your app, it would be rather artificial relationship from
offering to the item, in particular because those relationships
will be constantly changing on the offering side.

  
Great.  I'll stick with that.

Thanks!

Greg
thanks,
-marina

Greg Ederer wrote On 11/08/06 12:20,:
  
Hi Marina,

Marina Vatkina wrote:

    
Hi Greg,

If this is the case, why would you need to remove items by a specific
offering?

      
Good question.  A shopping cart can have more than one item containing a
particular offering.  I do this so that I can support behavior like,
"Buy two cats at the regular price, get a third cat at half price."  To
support this, (in a business class) I create 2 items.  The first item
has 'cat' as the offering, and the quantity set to 2.  The second item
has 'cat' as the offering, quantity 1, and a reference to a Discount
object with a 'percent off' value of .50f.  The discount gets applied
only to the second item.

I am anticipating that it will be common for a user to remove all of the
items that contain a particular offering (decided we don't need any cats
today).  So, I created a convenience method to handle this.  I also have
methods for removing a particular item, and for updating the quantity of
an item.

Does this make sense?

Thanks.

Greg

    
Greg Ederer wrote:

      
Hi Marina,

In my model, instances of Offering represent things that a Vendor
offers for sale.  Product and Service directly subclass Offering and
are, themselves, subclassed by classes representing more specialized
kinds of products and services (e.g., Subscription, Garment, et cetera).

A ShoppingCartItem has an Offering (as well as a quantity, a unit
price, a collection of Discounts, et cetera).

I suppose that I could establish a many-to-many relationship between
Offering and ShoppingCartItem.  Does that strike you as being a good
idea?
        
Would it be a many-to-one if item can have only one offering?

The solution most probably depends on the use case. If you don't the
remove
quite often, the bulk delete might be a better solution (as long as it
doesn't
intervene with the in-memory transaction processing as it happens
directly
in the database, and won't affect the cache).

regards,
-marina

      
Cheers,

Greg

Marina Vatkina wrote:

        
Hi Greg,

Does it mean that there is no relationship from Offering to Item?
Is it worth adding (and maintaining so that they are always at sync)?

thanks,
-marina

Greg Ederer wrote:

          
Hi,

I have a method that removes a persistent object from a collection
based on a property of the object being removed, like so:

  /**
   * Removes all ShoppingCartItems containing this
   * offering
   */
  public void removeItem(Offering offering)
  {
    List<ShoppingCartItem> iList = new
ArrayList<ShoppingCartItem>(getItems());
    for(ShoppingCartItem i : iList)
    {
      if(i.getOffering().equals(offering))
      {
        getItems().remove(i);
      }
    }
  }

Is this the best way to do this?

Cheers,

Greg

p.s.: I'm so glad I found this list.  I feel like I've been groping
in the dark with JPA.  Thanks for all the help! --G
-- 

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@ergonosis.com
| 360.379.1157
| | OpenDocument - OK <http://openoffice.org/>
|

            
-- 

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@ergonosis.com
| 360.379.1157
| | OpenDocument - OK <http://openoffice.org/>
|

        
-- 

| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@ergonosis.com
| 360.379.1157
| 
| OpenDocument - OK <http://openoffice.org/>
|

    

  


--
| E R G O N O S I S
| Greg Ederer
| Lead Developer
| greg@ergonosis.com
| 360.379.1157
| 
| OpenDocument - OK
|