Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EProxy and Hashes #120

Open
AnNeub opened this issue Jan 31, 2022 · 1 comment
Open

EProxy and Hashes #120

AnNeub opened this issue Jan 31, 2022 · 1 comment

Comments

@AnNeub
Copy link

AnNeub commented Jan 31, 2022

Hey @aranega

as I already mentioned in #119 I switched from static generated code to dynamic loaded. For some export function I have a lookup dictionary where I use 'EInt, EFloat, ...' (classes not strings) as key and set a converter function as value.
If a load the model dynamical the pyEcore classes (EInt, EFloat) will be referenced via a EProxy. Because the EProxy has its own hash, the pyEcore classes which are imported are different. The EProxy has an __eq__ which references to the real class but in this case the hashes are used.
Maybe it was not the best idea to use the class as key, but I want to share this experience with you.

Best regards,
Andreas

@aranega
Copy link
Member

aranega commented Feb 7, 2022

Hi @AnNeub !

Indeed, the hash thing for proxies is tricky. The same problem occurs in EMF with unresolved resources, but in your case, it would be better to avoid the proxy as Ecore is always known. I'll see if I can deal with a less lazy way of deserializing xmi, avoiding this for EMF/Ecore basic types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants