oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Starch, Michael D (388L)" <Michael.D.Sta...@jpl.nasa.gov>
Subject Re: Overriding equals/hashCode for the Product class
Date Wed, 12 Oct 2011 16:43:21 GMT
Chris,

Point taken.  I have constructed my code differently.

Here is another related question:  

In our branch we have three catalog functions that have very similar database back ends, Query,
ComplexQuery, and PagedQuery.  Unfortunately, complexQuery performs its work by first running
"query" and then running individual metadata requests for each id returned.  This is inefficient
from a database perspective as you are running many many queries, when a single query would
suffice (and that single query was run once to get the list to begin with).

According to our DBA we will see big gains if we eliminate this loop, and the complexities
of sorting the metadata have been solved (that was what yielded my pervious question).  Unfortunately,
that means moving some complex query code into the catalog, and thus needing to return 2 completely
different types from one method "query".  My first instinct is to add a complexQuery method
to the catalog interface (bad as it breaks older interfaces), or sub-interface the catalog
interface and add this method (better because old catalogs would work as they do now), but
seeing as you would like me to move this feature up to apache (assuming we can properly page
it), perhaps you have a better solution that will keep our branch more compatible with apache,
so I have less work to do to migrate my changes.

-Michael

On 11.10.2011, at 21:00, Chris A Mattmann wrote:

> Hi All,
> 
> On Oct 11, 2011, at 7:40 PM, Brian Foster wrote:
> 
>> the problem with implementing an equals and hashCode function for the Product object
is that it is not always created from db data... many of the objects in the structs package
are 'fill what I know at the moment'... no guarantee that any one member variable in the object
will always be set...
> 
> I totally agree with Brian on this. The lifecycle of any one of the FM objects in the
o.a.oodt.cas.filemgr.structs (and furthermore in any o.a.oodt.*.structs package) is that any
of the fields of the object may (or may not) be filled at any point in time. It really depends
on the lifecycle of the object, and the downstream use of them in a service, in the core,
or in some extension point. The objects are meant to be light-weight, and not representative
of the *full* set of information at any point in time unless absolutely necessary (thereby
lowering the total system footprint, etc.), making it more light-weight, etc.
> 
>> for instance when a Product is created on the client side for an ingest the productId
is not set until after ingestion... also the current trunk filemgr's Product object doesn't
have an ingested or received time attach to it... at least the last time I checked it didn't...
lol...
> 
> +1, you are right, it's still that way, for the above stated reasons.
> 
>> so an equals method which say just checked against productId and productName could
give a false positive in some cases... for example making two sequential calls to getProductById()
then calling equals (assuming we implemented it) on the 2 Product objects returned would return
true... but if the Product was updated between the 2 calls, equals really should return false
because the first Product object is out of date...
> 
> +1
> 
>> and doing a deep equals on the Product object would make the operation expensive...
the Product object is more meant to be an information carrier... I would recommend storing
your Products in a Map<String,Product> where the String key is ProductId
> 
> +1, agreed. Using a Map<String, Product> structure is a good way to obviate this,
and then to define some locally uniqueness key function inside of that map (or accept the
uniqueness of the product ID which *should be* unique at least within a single FM catalog).
> 
> Cheers,
> Chris
> 
>> On Oct 11, 2011, at 4:46 PM, "Starch, Michael D (388L)" <Michael.D.Starch@jpl.nasa.gov>
wrote:
>> 
>>> Chris et all,
>>> 
>>> Do you see any problems overriding the default equals, and hashCode methods in
the Product class (checking by memory address/reference) to something that checks to see if
the products logically represent the same thing (same id, name, etc)?
>>> 
>>> My issue is the following, I receive data back from the database, with multiple
lines representing a single product (this is a database thing, and the desired behavior).
 Thus if I iterate across the results, I will get multiple Product objects that represent
one real Product (and contain equivalent member variables).  In essence they are the same
"Product".  I can write cleaner, faster, code to combine the results, if I can test them for
equality and hash them directly, without first pulling out the productName, or Id.
>>> 
>>> This will be a problem if there is some code that expects two "Products" that
have identical member variables to fail the equality test if they are distinct objects.
>>> 
>>> Thanks,
>>> 
>>> -Michael
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 


Mime
View raw message