Well, that's the way I do things, but not everyone has caught on. I'll try
to drive that home. Also, what I find I have to do for things to work
correctly, is write my setter to be smart.
public void setFoo(Foo foo)
{
this.foo = foo;
if (this.foo == null)
fooOid = 0;
else
fooOid = foo.getOid();
}
Is that wrong?
Either way, I don't think this addresses the Collectio
But that still doesn't address the collection-descriptor problem.
I still think it would be a good "safety feature" to offer, as surely other
developers make the same mistakes our team does....
David
|---------+--------------------------->
| | Thomas Mahler |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED] |
| | |
| | |
| | 03/04/2003 02:29|
| | PM |
| | Please respond |
| | to "OJB Users |
| | List" |
| | |
|---------+--------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: OJB Users List <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: Re: Anybody else have this problem?/Feature Idea
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
I absolutely agree with Charles!
the automatic handling of foreign keys was build to let developers
concentrate on business objects and not on rdbms details.
Thomas
Charles Anthony wrote:
> Hi,
>
> Developer should only ever set foo, and should never set fooId.
>
> OJB manages all foreign keys.
>
> In our app, we don't generate setters for any id fields (primary or
> foreign), and we only have a getter for the PK. Therefore, the developers
> find it much harder to fiddle with the keys.
>
> Cheers,
>
> Charles.
>
>
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>Sent: 04 March 2003 17:20
>>To: [EMAIL PROTECTED]
>>Subject: Anybody else have this problem?/Feature Idea
>>
>>
>>There are some aspects of OJB that require/encourage having
>>two pieces of
>>data to represent single relationship.
>>
>>1) When I have an referenceDescriptor, I have to have a
>>fooOid, and a Foo,
>>both of which are two ways of referring to the same thing.
>>2) When I have a collectionDescriptor, I have a collection on
>>one side, and
>>a fooOid on the other, and sometimes I also have the Foo.
>>
>>We have repeatedly run into problems where the developer will
>>correctly set
>>one of the many pieces of data, but not all of them. This usually
>>manifests itself as an intermittent bug because the cached
>>objects don't
>>match the objects that are loaded from the database if they're
>>not in the
>>cache.
>>
>>It would be really cool (IMO) if OJB had a mode that would
>>validate this
>>stuff when it goes to write to the database.
>>
>>What do the rest of you think?
>>
>>David
>>
>>
>>
>>
>>This message contains information from Equifax Inc. which may be
>>confidential and privileged. If you are not an intended
>>recipient, please
>>refrain from any disclosure, copying, distribution or use of this
>>information and note that such actions are prohibited. If you have
>>received this transmission in error, please notify by e-mail
>>[EMAIL PROTECTED]
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
> This email and any attachments are strictly confidential and are intended
> solely for the addressee. If you are not the intended recipient you must
> not disclose, forward, copy or take any action in reliance on this
message
> or its attachments. If you have received this email in error please
notify
> the sender as soon as possible and delete it from your computer systems.
> Any views or opinions presented are solely those of the author and do not
> necessarily reflect those of HPD Software Limited or its affiliates.
>
> At present the integrity of email across the internet cannot be
guaranteed
> and messages sent via this medium are potentially at risk. All liability
> is excluded to the extent permitted by law for any claims arising as a
re-
> sult of the use of this medium to transmit information by or to
> HPD Software Limited or its affiliates.
>
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
