Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMap and resolved keys
EMap and resolved keys [message #891904] Tue, 26 June 2012 13:32 Go to next message
Manuel Ihlenfeld is currently offline Manuel IhlenfeldFriend
Messages: 6
Registered: June 2012
Junior Member
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 14:00 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30354
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
Re: EMap and resolved keys [message #891966 is a reply to message #891909] Tue, 26 June 2012 17:23 Go to previous messageGo to next message
Manuel Ihlenfeld is currently offline Manuel IhlenfeldFriend
Messages: 6
Registered: June 2012
Junior Member
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,

- 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).

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.

Are there any other issues with this approach I haven't thought of?
Re: EMap and resolved keys [message #892005 is a reply to message #891966] Tue, 26 June 2012 19:49 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30354
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.
Previous Topic:[XCore] Overriding implementation of a super class feature in a subclass
Next Topic:How to use getResourceLocator().getImage to get image by absolute path
Goto Forum:
  


Current Time: Wed Aug 21 13:31:30 GMT 2019

Powered by FUDForum. Page generated in 0.01915 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top