pete stein wrote:Perhaps you should only use the invariants: the ID, the birth date, and perhaps the name at birth.
Mike Simmons wrote:You could require than any time one of those fields is changed, the object must first be removed from any maps or sets it's in. ....could get messy.
Pat wrote:How does an object know how many maps, hashsets, lists, etc that its in? Its really unknowable, which is harder than NP-hard.
Pat wrote:If you had an object in a HashMap and in an ArrayList or vector, you would have to remove and replace it in both. Very ugly. It would lead to object listeners, and zillions of callbacks.
Mike Simmons wrote:I don't think there's any reason to worry about ArrayLists or Vectors - these don't depend on hashCode() at all. And when they do depend on equals(), e.g. for contains(), they always use the current data for comparison. There's no caching of some old data the way there is in a hash table or hash set, where the bucket position is based on the original hash code, and thus may be out of date.
Pat wrote:So if there are old flavors of the Foo in an ArrayList/Vector, or anywhere, when you change it, you either chase down all the locations, or have two (or more) objects that claim to be the one true Foo instance, but are in fact different.
Mike Simmons wrote:
Pat wrote:So if there are old flavors of the Foo in an ArrayList/Vector, or anywhere, when you change it, you either chase down all the locations, or have two (or more) objects that claim to be the one true Foo instance, but are in fact different.
No - you'd have one or more instances where isValid is false, and you'd have one instance where isValid is true.
Pat wrote:you have a bunch of objects that are not correct and you don't know how many of them there are.
Mike Simmons wrote:And why would it be important to know how many there are? Are you dealing with memory leaks too?
Mike Simmons wrote:
Pat wrote:you have a bunch of objects that are not correct and you don't know how many of them there are.
And why would it be important to know how many there are? Are you dealing with memory leaks too?
If there are X > 0 bad Foo objects, it really doesn't matter how many there are. I'm not as worried about memory leaks as logical leaks.
Mike Simmons wrote:So, did you read anything else in my reply?
Pat Farrell wrote: While the ID is the primary key in the database, its a lousy field for telling if humans are equal. Perhaps two otherwise identical records are two people, perhaps they are one person entered twice into the system, and our duplication check code failed. Its a hard problem.
apigee, a better way to API!
Nitesh Kant wrote: Interesting (hard) problems always create different opinions and let us respect each other's views!
Moving to Intermediate forum.
I feel that since the human id is the primary key in the DB then the ideological limits have somewhere been breached so it probably makes sense to breach them everywhere
This automatically solves the programmatic problem as human_id will never change. Am i correct?
Pat Farrell wrote:
Nitesh Kant wrote: Interesting (hard) problems always create different opinions and let us respect each other's views!
Moving to Intermediate forum.
Well, you can move it, but as I posted long ago, there are very few threads that stay in Advanced, and once in a while, it would be good to see a hard problem stay there.
apigee, a better way to API!
Cheers, Martijn,
Twitter.
Steve
Steve Luke wrote:Then the data-layer factory keeps the Human data up to data, takes it out of service when needed to, etc... and your business layer has a consistent view of the current data with a simple interface and a basic mechanism for maintaining equality in respects to data.
You had brought up concerns previously about using the human_id as a good marker for equality because it does not sort out duplicate data points that passed by your data entry duplication checks. This is a problem to be addressed on your data entry side and not on your data access side. Like you said, there is little or no way to make sure that 'Steve Luke' is the same as 'Steve Luke' on the data access side, we could be quite different people (or not). But if we have the same human_id, we can be expected to be the same person. On the other hand, if I already exist in the database, then at the data entry level you can spit back a message 'This guy Steve Luke already exists, do you want to make a new one, or update the old one?' rather easily.
Steve
SCJP 1.4 100%
SCJD 99.5%
You are HERE! The other map is obviously wrong. Better confirm with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|