EMap and resolved keys [message #891904] |
Tue, 26 June 2012 09:32  |
Eclipse User |
|
|
|
Hello!
Suppose I have two resources Res and Rmap.
Rmap essentially contains a EMap mapping objects from Res to some values.
That is, Res contains the keys used to access the map.
During debugging I observed that EcoreEMap lazily initializes its internal
hash table with the first invocation of get(key) effectively using
key.hashCode() as hash value.
When unloading and subsequently loading Res all contained objects become
proxies. By resolving the proxies I get new objects representing the keys.
However, the maps internal hash table was set up using the old (now
proxies) object's hash codes. Subsequent lookups using the resolved keys
fail (return null) because their hash codes are not in line with the hash
table.
How can I access the map using the resolved keys?
If necessary, I could send an example based on the Extended Library Model
Example where Items are mapped to Shelfs.
Regards
Manuel
|
|
|
Re: EMap and resolved keys [message #891909 is a reply to message #891904] |
Tue, 26 June 2012 10:00   |
Eclipse User |
|
|
|
Manuel,
Comments below.
On 26/06/2012 3:32 PM, Manuel Ihlenfeld wrote:
>
> Hello!
>
> Suppose I have two resources Res and Rmap.
>
> Rmap essentially contains a EMap mapping objects from Res to some
> values. That is, Res contains the keys used to access the map.
>
> During debugging I observed that EcoreEMap lazily initializes its
> internal hash table with the first invocation of get(key) effectively
> using key.hashCode() as hash value.
Yes.
>
> When unloading and subsequently loading Res all contained objects
> become proxies. By resolving the proxies I get new objects
> representing the keys. However, the maps internal hash table was set
> up using the old (now proxies) object's hash codes. Subsequent lookups
> using the resolved keys fail (return null) because their hash codes
> are not in line with the hash table.
I see. You'd basically have the same problem with a regular HashMap,
i.e., you'd need to build a new one for the new objects...
>
> How can I access the map using the resolved keys?
Not an easy problem to work around... You could copy the map, clear the
original, and putAll the copy back to the original.
>
> If necessary, I could send an example based on the Extended Library
> Model Example where Items are mapped to Shelfs.
It's not a problem with any nice solutions; converting an object to a
proxy doesn't even produce notifications nor would you want to check all
keys to see if they've been turned into proxy on each lookup...
>
> Regards
> Manuel
|
|
|
|
Re: EMap and resolved keys [message #892005 is a reply to message #891966] |
Tue, 26 June 2012 15:49  |
Eclipse User |
|
|
|
Manuel,
Comments below.
On 26/06/2012 7:23 PM, Manuel Ihlenfeld wrote:
>
> Ed,
>
> thank you for your help. I feared that I'd need to rebuild the map.
>
> However, I think I may have found another solution. In our case, all
> key objects have IDs which never change (UUIDs). Instead of
> key.hashCode() its ID's hash code could be used.
>
> I gave it a try and it seems to work. I've
>
> - created a subclass of EcoreEMap with a modified
> hashOf(key) method which returns the ID's hash code,
That makes sense.
>
> - modified the generated PlacementImpl#getItemToShelfMap()
> to lazily create an instance of my custom map class instead
> of EcoreEMap (Placement is the map's container class), and
>
> - modified the generated ItemToShelfImpl#getHash()
> to also return the ID's hash code (ItemToShelfImpl
> is the generated Map.Entry subclass).
Yes, that's needed too.
>
> It works using resolved keys for lookups (because generated map
> entries resolve their keys, making the stored key equal to the given
> key). Using proxy keys fails, however. That is, I just need to ensure
> to not use proxies as keys for lookups.
Unresolveable proxies are generally broken things anyway...
>
> Are there any other issues with this approach I haven't thought of?
No, that sounds complete. You might use the full URI as a key, i.e, the
result of EcoreUtil.getURI, which for proxies returns the proxy URI.
|
|
|
Powered by
FUDForum. Page generated in 0.03606 seconds