Rename children and parent still shows up-to-date

[karthur1]

Say that I do a "Get Latest" on my assembly, then I rename some of the children that are used in it.  Of course, the children show to not be in my workspace, but the Vault browser still shows my assembly as up-to-date (white dot in VE).  In previous versions of Vault, it would show the assembly as out-of-date (with a red dot in VE), but now it shows as being up-to-date.

Now if I open the assembly in Inventor, the Inventor vault browser will show files with a red dot.  I know that I can do a "Refresh" from the Inventor vault browser and get the files in sync again, but this is somewhat confusing and an extra step that shouldnt be.

The way it is now, the white dot, just means that the file is in your workspace.. may or may not be up-to-date.  If you want to know for sure, open it in Inventor and find out.  I think it should turn to a red dot when the children are renamed.

I think we have taken a step back here.  Am I the only that feels this way about this?

Kirk A.

Windows 7 x64 -12 GB Ram
Intel i7-930 @ 3.60ghz
nVidia GTS 250 -1GB (Driver 301.42)
INV Pro R2013, SP1.1 (update1)
Vault Basic 2013

[olearya]

Hey Kirk,

This change in behavior relates to changes in the rename workflows - we no longer update file relationships in real time to improve Vault performance and enable the rename workflow in situations where parent files may be locked.

As of 2013 we update the references on file download - check out / check in.  So relationships are resolved as needed or "on demand" - see the opening comments here under renaming files:

http://wikihelp.autodesk.com/Vault/enu/Help/Help/0001-Using_Va1/0021-Manage_F21

[karthur1]

---

@olearya wrote:

This change in behavior relates to changes in the rename workflows - we no longer update file relationships in real time to improve Vault performance and enable the rename workflow in situations where parent files may be locked.

Allan,

Thanks for that.  I think I remember reading that somewhere after reading what you wrote. I think that it must update the relationship if it changes.  This just causes us too many problems later because from Vault, it looks like we have the latest file. 

Is it really that big of a hit on performance?  Its not like we are constantly renaming files, but when we do, we want Vault to give us the correct status.

Maybe give us an option from ADMS to update the relationships or not.

Kirk

[minkd]

Yes, it has a potentially *huge* impact on performance - with the old way if you rename a child that is used by many parents, then all of those parents must be downloaded, updated and checked-in. Now we fix the relationships of a particular assembly when it is downloaded if it has a child that has been renamed.

Also, the old way did not work if you were using revisioning (we wouldn't let you rename in that case).  So say you have revision A of a parent that references revision A of a child and you do a quick update of the child to rename it (so it stays revision A).  If there is a revision B of the parent (which may not even reference that child anymore), then we couldn't fix revision A of the parent.  Also due to object based security, you may not have permission to update all the parents that would need it.  This all just works with the new way.

-Dave

[karthur1]

---

@minkd wrote:

Yes, it has a potentially *huge* impact on performance - with the old way if you rename a child that is used by many parents, then all of those parents must be downloaded, updated and checked-in. Now we fix the relationships of a particular assembly when it is downloaded if it has a child that has been renamed.....

---

"all those parents must be dowloaded, updated and checked-in".... we have to download the parents with the "new" way as well.  With the old way, we knew which parents were out of date because they have a red dot in the browser.  With the new way, we no longer get the red dot, so the vault status is not correct.

If I didn't have the parent on my workspace when I renamed the children, then what you are saying is correct. The problem is when I DO have a copy of the parent on my workspace before the rename.

Kirk

[olearya]

Hey Kirk,

Dave is indicating here that the effect is across potentially 100's of assemblies - not just the 1 you are working on - changing a bolt used in all of your assemblies using the "old way" was an incredibly resource intensive process and generally unnecessary.

I am not sure you would have your entire Vault downloaded to your workspace right?

[karthur1]

Allan,

No, your right, I dont have the entire vault downloaded to my workspace.

I understand what you and Dave are saying.  The old way was very resource intensive if child is used in many parent files because Vault was actually downloading and updating the parents. Since the parent was changed by Vault, the local copy is now out-of-date (thus the red dot now shows). When the child is used in many parent files, it could take a long time to process all these. So, rather than Vault doing this process, that is being defered until the file is downloaded from vault and opened in Inventor.  I think I have that right.

Do you understand where I am coming from?  I am saying that the references MUST be updated, otherwise, the vault status is not correct. Its not everyday that I rename the fasteners in my database (actually, I have never done that). And, I can see where using the old way it would take a very long time to complete it because they are used in 1,000's of iams.

But, quite frequently, I will rename parts that are directly related to my team project.  It is confusing to other team members when they open an assembly and see a red dot in their Inventor Vault browser, even though they have a white dot (latest file) in the Vault Explorer browser beside the parent.

Kirk