Re: Fwd: Using a non-existent collection inside a query

[Jakob Braeuchi]

hi edson,

[EMAIL PROTECTED] wrote:
hi edson,

frankly, i'm still confused...



Sorry... I think I don't have sufficient english skills to make more clear...


i understand that collection-proxies do not seem to help because of the
way you built your gui :(


Thanks, I think you had some "experiences" (some good, some bad) with swing too... But
that's not our point, right ;-)

when you say the relationship does not exist, does this mean that it's
not defined in the repository ?


Yes, I mean that this is not defined in repository. Neither the collection-descriptor,
neither the field used when querying.
i saw the sample code you posted some days ago. now it's clear how you do it.


what do you mean by mounting the query ?



Imagine the object:

public class Customer {
  public Integer id;
  public String name;
}
Now I load some class that will notify (internally, in my app) that a new table is 
avaliable
in database (the documents table), and I can make queries by the document number. But I
don't have a "document" neither "documentNumber" in Customer class.
To query I must do

Criteria c = new Criteria();
c.addEqualTo("document.documentNumber", "12345");
But OJB will throw exception: where is no document field in Customer. So I add 
dinamically a
document field as an collection descriptor. Uau, OJB now queries the database! Fine 
that's
all I want.
But, when I tried to store any Customer object, OJB throw an exception saying that 
there is
no document field. Even if I use proxies=true (or not), lazy=true (or not),
auto-update=false (or not) and so on. Nothing works. Always exception.
ojb needs this field (better: the collection referenced by this field) to handle 
 the m:n-implementors in case of an m:n-relationship.

I've detected that the problem is because OJB is trying to set key fields in 
referenced
objects (including my document collection - that doesn't exists at all, is just an 
artifact
to make queries) - before storing...
afaik this should only be done if getCascadeStore() is true. imo the method 
storeCollections() needs some refactoring to separate handling of 
m:n-implementors, but that's another issue.


what other parts of ojb did you need to modify to achieve this behaviour ?



None. Just that if does the job. I had think a lot about this, and I get the 
conclusion that
OJB should not set keys in referenced object when auto-update=false, right? Or not?
As long as I don't want do change any default behavior of OJB, I've created the virtual
attribute, and used it...
jakob

Thanks again,

Edson Richter

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



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