I used both Hibernate docs and Hibernate in Action to come up with this
mapping, it seems to be the 'standard' way to doing this (mapping a relation
with attributes, in my case, quantity). The example you cited is a relation
without attributes, so I don't think it's suitable for me. From Hibernate in
Action:

'you should ask whether it might be better to map CategorizedItem
[AAndBJoin] as an entity class and use two one-to-many associations.'

At any rate, I posted just before seeing your message. The problem with
deleting all elements in the Collection (which was 99% of my last post!) is
resolved. 

The only problem that remains is when I save a new ObjectA and at the same
time associate ObjectBs, that I don't have an idObjectA to assign to the FK
column of the aandbjoins table, so the AAndBJoin Objects are improperly
saved (idObjectA is null), and are not loaded when I load the ObjectA (see
my last message). Your suggestion didn't have anything to do with this
problem did it?

I have tried making the two foreign key columns in AAndBJoin nullable=false,
like this:

public class AAndBJoin
{
  private Long id;
  private ObjectA objectA;
  private ObjectB objectB;

  @Column(name="idAAndBJoin")
  @Id @GeneratedValue(strategy = GenerationType.AUTO)
  public Long getId() 

  @ManyToOne
  @JoinColumn(name="idObjectA",nullable=false)
  public ObjectA getObjectA()

  @ManyToOne
  @JoinColumn(name="idObjectB",nullable=false)
  public ObjectB getObjectB() 

but when I save a new ObjectA I get an 'not-null property references a null
or transient value' error. 

As you can see I am using an id as the Primary Key. If I were to use a
Composite Primary Key -- idObjectA and idObjectB -- would this 'force'
Hibernate to fill-in values for these ids, even when saving a new ObjectA?

Thanks!
Bob



Mike Horwitz wrote:
> 
> I think your issue is that in your case you want the one-to-many side of
> the
> relationship to own the relationship. In order to make this happen you are
> going to have to change your annotations. The following section of the
> Hibernate manual should help: http://tinyurl.com/ypdln3 look for section
> 2.2.5.3.2.1.
> 
> Mike
> 
> On 10/31/07, syg6 <[EMAIL PROTECTED]> wrote:
>>
>>
>> Well what's curious is that with my other 'normal' ManyToMany (see my
>> previous post. ObjectA has a Collection of ObjectC) if from my ObjectA
>> form
>> I delete all ObjectCs, the 'objectcs' Request parameter is 'null' and
>> Hibernate correctly deletes all ObjectC objects.
>>
>> But with my ObjectB Collection, this does not work, I assume because I am
>> doing a 'manual' ManyToMany, in other words ObjectA and ObjectB have a
>> OneToMany relation with AAndBJoin, and AAndBJoin has a ManyToOne to both
>> ObjectA and ObjectB. The behavior should be the same, no? If I send
>> 'null',
>> it should delete all elements from the Collection, just as it does with
>> my
>> ObjectC Collection. But it does not.
>>
>> At any rate, I've tried manually deleting all ObjectBs from the
>> Collection;
>> In my ObjectAFormController onSubmit() I tried the following (only when
>> the
>> 'objectbs' Request parameter is null):
>>
>> 1. Load ObjectA from database (to get existing ObjectB Collection).
>> 2. Use ObjectBManager to get() each ObjectB
>> 3. Use ObjectBManager to remove() each ObjectB
>> 4. Call ObjectAManager.save()
>>
>> And I get a 'deleted object would be re-saved by cascade (remove deleted
>> object from associations):' error, as I knew I would. And if I instead
>> call
>> objectA.setObjectBs(null) I get a 'A collection with
>> cascade="all-delete-orphan" was no longer referenced by the owning entity
>> instance' error.
>>
>> The only difference I can see between the Collection of ObjectBs and
>> ObjectCs is that in my ObjectAFormController onSubmit(), after this line:
>>
>> ObjectA objectA = (ObjectA) command;
>>
>> ... if in the objectaform.jsp I have deleted all of the ObjectC elements
>> from the Collection, objectA.getObjectCs() is null. Correct! And
>> Hibernate
>> goes on to delete these ObjectBs from the database. But if I have deleted
>> all of the ObjectB elements from the Collection, objectA.getObjectBs() is
>> NOT null; it has the 'old' data, the Collection as it existed before
>> doing
>> the deletes. As such, Hibernate does not update the database. And I
>> assume
>> that's also why if I try to manually delete the elements, I am getting an
>> error.
>>
>> Both Collections have a Custom PropertyEditor. The difference is that
>> ObjectC only implements setAsText():
>>
>> public void setAsText(String id)
>> {
>> ObjectC objectC = objectCManager.get(new Long(id));
>> setValue(objectC);
>> }
>>
>> whereas the Custom PropertyEditor for ObjectB, because I use my own Model
>> Object (AAndBJoin) to represent the Join, and has to grab a bunch of
>> values
>> from text and hidden fields in the form to create AAndBJoin Objects,
>> implements setValue():
>>
>> public void setValue(Object object)
>> {
>> // array of values sent from text/hidden inputs in form
>> String[] strings = (String[])object;
>>
>> Set<AAndBJoin> aAndBJoins = new LinkedHashSet<AAndBJoin>();
>>
>> for (number of text/hidden inputs in the page)
>> {
>>    AAndBJoin aAndBJoin = new AAndBJoin();
>>    aAndBJoin.setId(new Long(strings[0]));
>>    aAndBJoin.setObjectA(objectAManager.get(new Long(strings[1])));
>>    aAndBJoin.setObjectB(objectBManager.get(new Long(strings[2])));
>>    aAndBJoin.setQuantity(new Integer(strings[3]));
>>    aAndBJoins.add(aAndBJoin);
>> }
>> super.setValue(aAndBJoins);
>> }
>>
>> Anyway, the point is if I delete all ObjectC elements, ObjectC's Custom
>> PropertyEditor is not being called (because since it's null there's no
>> reason to call it) and when I call objectA.getObjectCs() I get null, ok.
>> But
>> when I delete all ObjectB elements, even though its Custom PropertyEditor
>> isn't called either, when I call objectA.getObjectBs() I get the old
>> Collection info, before the delete. Which is why Hibernate doesn't update
>> the database, and why I get errors if I try to delete them manually.
>>
>> Odd, inconsistent behavior, no? It seems that since I am using my own
>> Model
>> Object (AAndBJoin) to represent the relation, I need to do something else
>> to
>> make Hibernate aware that all elements have been deleted. But I have no
>> idea
>> what!
>>
>> Incidentally, any ideas about the other problem? Where when I create a
>> new
>> ObjectA and associate various ObjectB elements, those AAndBJoin Objects
>> are
>> saved incorrectly, with idObjectA=null, because when I call
>> objectA.save()
>> I
>> still don't have an idObjectA?
>>
>> Thanks, sorry for the long post,
>> Bob
>>
>>
>> DNewfield wrote:
>> >
>> > syg6 wrote:
>> >> Something else I have noticed: deleting members of the AAndBJoin
>> >> Collection
>> >> seems to be working, more or less, now that I put the DELETE_ORPHAN
>> >> Hibernate Annotation. But there is one case where it does NOT work --
>> >> when
>> >> you delete all of the elements. When you delete all of the elements,
>> the
>> >> 'AAndBJoin' Request parameter is of course null. What Hibernate should
>> do
>> >> in
>> >> this case is delete all elements. But what it in fact does, is
>> nothing.
>> >>
>> >> It seems that in order for Hibernate to properly delete elements from
>> a
>> >> Collection, at least one element has to be sent in the Request. Thus,
>> if
>> >> you
>> >> had 4 and deleted 3, 1 element is sent in the Request and Hibernate
>> >> compares
>> >> the Collection before and after, and properly deletes 3. But if you
>> >> delete
>> >> all 4, in the Request 'null' is received, Hibernate seems to do no
>> >> comparison, and deletes nothing. Ugh.
>> >
>> > You need to detect this case, because assigning "null" to the the
>> > collection attribute is wrong--the appropriate answer is to retrieve
>> the
>> > (hibernate managed) collection, and either remove each item from it or
>> > clear() the collection, then re-setting the (same) cleared collection
>> to
>> > the attribute.
>> >
>> > -Dale
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Many-to-many-collection-problem-tf4670322s2369.html#a13507645
>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Many-to-many-collection-problem-tf4670322s2369.html#a13508465
Sent from the AppFuse - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to