|
| Re: EMap and resolved keys [message #891909 is a reply to message #891904] |
Tue, 26 June 2012 14:00   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: EMap and resolved keys [message #892005 is a reply to message #891966] |
Tue, 26 June 2012 19:49 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02877 seconds
] 
Search
Help
Register
Login
Home
