Re: Anybody else have this problem?/Feature Idea

Wed, 05 Mar 2003 08:49:04 -0800

I do this too, and with just about all my get and set methods. I believe it provides some kind of data which the developer or user can look at. If the value is 0, then there must be something busted if you expected something else. I do the same with Collections and business objects I create.


On Wednesday, Mar 5, 2003, at 10:41 US/Eastern, [EMAIL PROTECTED] wrote:


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]



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

Reply via email to