|
|
|
| Re: Question re href and @children [message #430121 is a reply to message #430054] |
Mon, 11 May 2009 16:07   |
 Alan
Messages: 44
Registered: July 2009 |
Member |
|
|
Hi Ed,
I used the eKeys and set it to use the id attribute which is a unique
identifier for everything in my model
but the xml did not change and still used the old @childre.index style.
I feel like I am missing something easy. Any ideas ?
thanks,
Alan.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gu1vi7$j2q$1@build.eclipse.org...
> Alan,
>
> Comments below.
>
> Alan wrote:
>> Hello,
>>
>> I am having a strange issue with hrefs.
>> I have 2 resources.
>> In the first I have a number of Object As which contains a collection of
>> Object Bs (containment = true)
>> (I also have something things above A but we'll focus on A and B for
>> example)
>> In the second I have a reference to a collection of Object Bs
>> (containment = false)
>>
>> The href for one of the Object Bs in the second resource reads like this:
>> href="resource1.config#//@children.2/@children.3/@myobjectBs.0
>>
>> The issue arises when I delete an Object A.
>> In the first resource it is now found at @children.2/@children.2
>> instead of at @children.2/@children.3
>>
> Yes, that's expected.
>> This only occurs if I delete an Object A that was not the last created
>> one.
>> In other words it seems as if that format is like an index.
>>
> Yes, exactly.
>> So when I delete one Object A any ObjectAs created after it have their
>> "indexes" updated.
>>
> Indeed the format it fragile with respect to reordering.
>> However the second resource does not update to reflect this.
>>
> It makes a difference whether the proxy is resolved or not. If it's not
> resolved yet, it will end up keeping the same proxy URI and will point to
> a different object.
>> So when I try to restart the application the collection of ObjectBs from
>> resource 2 does not find an object.
>>
>> I confirmed that this was what was happening by changing the reference
>> manually in the xml file of the second resource
>> So If I change index to reflect resource 1 it works fine.
>>
>> I tried making sure that resource1 was saved first and then resource2 but
>> it made no difference.
>>
> Whether proxies have been resolved makes a difference.
> EcoreUtil.resolveAll can be used to force all proxies to be resolve.
>> Has anyone any ideas as to why this is happening an how I might fix it ?
>>
> If possible take advantage of EReference.eKeys. I.e., identify an
> attribute or combination of attributes in A that make it unique with
> respect to the containment reference. The serialization will then look
> like @children[key='value'] and will be resilient with respect to
> reordering.
>> thanks,
>> Alan.
>>
>>
>>
|
|
|
| Re: Question re href and @children [message #430122 is a reply to message #430121] |
Mon, 11 May 2009 16:14 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000007080502050309050308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alan,
Should the id EAttribute had isID be true? If it's unique across the
whole resource, then yes....
Try setting a breakpoint in BasicEObjectImpl.eURIFragmentSegment. Pay
special attention to this part since eKeys.isEmpty should be false
according to your assertion that you've specified a key.
else if (eStructuralFeature.isMany())
{
EList<EAttribute> eKeys = ((EReference)eStructuralFeature).getEKeys();
if (eKeys.*isEmpty*())
{
Alan wrote:
> Hi Ed,
>
> I used the eKeys and set it to use the id attribute which is a unique
> identifier for everything in my model
> but the xml did not change and still used the old @childre.index style.
> I feel like I am missing something easy. Any ideas ?
>
> thanks,
> Alan.
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gu1vi7$j2q$1@build.eclipse.org...
>
>> Alan,
>>
>> Comments below.
>>
>> Alan wrote:
>>
>>> Hello,
>>>
>>> I am having a strange issue with hrefs.
>>> I have 2 resources.
>>> In the first I have a number of Object As which contains a collection of
>>> Object Bs (containment = true)
>>> (I also have something things above A but we'll focus on A and B for
>>> example)
>>> In the second I have a reference to a collection of Object Bs
>>> (containment = false)
>>>
>>> The href for one of the Object Bs in the second resource reads like this:
>>> href="resource1.config#//@children.2/@children.3/@myobjectBs.0
>>>
>>> The issue arises when I delete an Object A.
>>> In the first resource it is now found at @children.2/@children.2
>>> instead of at @children.2/@children.3
>>>
>>>
>> Yes, that's expected.
>>
>>> This only occurs if I delete an Object A that was not the last created
>>> one.
>>> In other words it seems as if that format is like an index.
>>>
>>>
>> Yes, exactly.
>>
>>> So when I delete one Object A any ObjectAs created after it have their
>>> "indexes" updated.
>>>
>>>
>> Indeed the format it fragile with respect to reordering.
>>
>>> However the second resource does not update to reflect this.
>>>
>>>
>> It makes a difference whether the proxy is resolved or not. If it's not
>> resolved yet, it will end up keeping the same proxy URI and will point to
>> a different object.
>>
>>> So when I try to restart the application the collection of ObjectBs from
>>> resource 2 does not find an object.
>>>
>>> I confirmed that this was what was happening by changing the reference
>>> manually in the xml file of the second resource
>>> So If I change index to reflect resource 1 it works fine.
>>>
>>> I tried making sure that resource1 was saved first and then resource2 but
>>> it made no difference.
>>>
>>>
>> Whether proxies have been resolved makes a difference.
>> EcoreUtil.resolveAll can be used to force all proxies to be resolve.
>>
>>> Has anyone any ideas as to why this is happening an how I might fix it ?
>>>
>>>
>> If possible take advantage of EReference.eKeys. I.e., identify an
>> attribute or combination of attributes in A that make it unique with
>> respect to the containment reference. The serialization will then look
>> like @children[key='value'] and will be resilient with respect to
>> reordering.
>>
>>> thanks,
>>> Alan.
>>>
>>>
>>>
>>>
>
>
>
--------------000007080502050309050308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alan,<br>
<br>
Should the id EAttribute had isID be true? If it's unique across the
whole resource, then yes....<br>
<br>
Try setting a breakpoint in BasicEObjectImpl.eURIFragmentSegment. Pay
special attention to this part since eKeys.isEmpty should be false
according to your assertion that you've specified a key.<br>
<br>
else if (eStructuralFeature.isMany())<br>
{<br>
EList<EAttribute> eKeys =
((EReference)eStructuralFeature).getEKeys();<br>
if (eKeys.<b>isEmpty</b>())<br>
{<br>
<br>
<br>
<br>
Alan wrote:
<blockquote cite="mid:gu9ig7$s4$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I used the eKeys and set it to use the id attribute which is a unique
identifier for everything in my model
but the xml did not change and still used the old @childre.index style.
I feel like I am missing something easy. Any ideas ?
thanks,
Alan.
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:gu1vi7$j2q$1@build.eclipse.org">news:gu1vi7$j2q$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Alan,
Comments below.
Alan wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
I am having a strange issue with hrefs.
I have 2 resources.
In the first I have a number of Object As which contains a collection of
Object Bs (containment = true)
(I also have something things above A but we'll focus on A and B for
example)
In the second I have a reference to a collection of Object Bs
(containment = false)
The href for one of the Object Bs in the second resource reads like this:
href="<a class="moz-txt-link-abbreviated" href=" mailto:resource1.config#//@children.2/@children.3/@myobjectB s.0 ">resource1.config#//@children.2/@children.3/@myobjectBs.0</a >
The issue arises when I delete an Object A.
In the first resource it is now found at @children.2/@children.2
instead of at @children.2/@children.3
</pre>
</blockquote>
<pre wrap="">Yes, that's expected.
</pre>
<blockquote type="cite">
<pre wrap="">This only occurs if I delete an Object A that was not the last created
one.
In other words it seems as if that format is like an index.
</pre>
</blockquote>
<pre wrap="">Yes, exactly.
</pre>
<blockquote type="cite">
<pre wrap="">So when I delete one Object A any ObjectAs created after it have their
"indexes" updated.
</pre>
</blockquote>
<pre wrap="">Indeed the format it fragile with respect to reordering.
</pre>
<blockquote type="cite">
<pre wrap="">However the second resource does not update to reflect this.
</pre>
</blockquote>
<pre wrap="">It makes a difference whether the proxy is resolved or not. If it's not
resolved yet, it will end up keeping the same proxy URI and will point to
a different object.
</pre>
<blockquote type="cite">
<pre wrap="">So when I try to restart the application the collection of ObjectBs from
resource 2 does not find an object.
I confirmed that this was what was happening by changing the reference
manually in the xml file of the second resource
So If I change index to reflect resource 1 it works fine.
I tried making sure that resource1 was saved first and then resource2 but
it made no difference.
</pre>
</blockquote>
<pre wrap="">Whether proxies have been resolved makes a difference.
EcoreUtil.resolveAll can be used to force all proxies to be resolve.
</pre>
<blockquote type="cite">
<pre wrap="">Has anyone any ideas as to why this is happening an how I might fix it ?
</pre>
</blockquote>
<pre wrap="">If possible take advantage of EReference.eKeys. I.e., identify an
attribute or combination of attributes in A that make it unique with
respect to the containment reference. The serialization will then look
like @children[key='value'] and will be resilient with respect to
reordering.
</pre>
<blockquote type="cite">
<pre wrap="">thanks,
Alan.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------000007080502050309050308--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03071 seconds
] 
Search
Help
Register
Login
Home
