Migration again: (when) does FWM script run?

[Sam Karli]

In a previous topic I have already tried to understand the circumstances of custom migration of ArchiCAD objects ( https://community.graphisoft.com/t5/GDL/How-to-migrate-OFF-Archicad-library-object/td-p/343848 ), now I need it, again, and it still doesn't work.

To condensate my question to the simplest form, it is:

when migrating, if I write an one liner FWM script:

parameters sSomeParameter = "Some Value"

(and nothing more) should be value of the (obviously existing) sSomeParameter's value set to "Some Value"?
Note that for me migration DOES occur, migration table is filled out, old objects are changed to new objects accordingly, but I have never saw any effects of FWM script and don't now what the problem is.

Code samples of FWM Scripts look like they are filled with **beep** (irrelevant looking subroutine calls etc.) that doesn't seem to be must-be (like TO_GUID, FROM_GUID etc.)

But who knows, maybe FWM scripts have a must-have format, sequence, etc.

Thanks in advance.

[Sam Karli]

Ah, I see to have a solution to my problem after some testing.

Now I live in a real-word environment and sometimes I have to improve my libparts that are already placed in plans, and sometimes these aren't compatible on a parameter level, so I need to change their parameters in a pre-programmed way, and this means migration, but at the end of the day I want to see "the same" objects, so "Door 27" should be "Door 27" but with different parametrization.

The workflow goes that I save the edited object "as a new library part", having the same name, this way giving it a new UUID. Then I can use the old UUID in the migration table (no AutoMigrate) and have a Forward migration script with a setmigrationguid with the new UUID. This is a simple way of migrating while object name (for the users) is not changed.

One remark that the developer has to keep track of the loaded objects while developing: when is the old and when is the new library part loaded (actually the both can be loaded at once).

[Barry Kelly]

---

@Sam Karli wrote:

One remark that the developer has to keep track of the loaded objects while developing: when is the old and when is the new library part loaded (actually the both can be loaded at once).

---

They can be loaded at the same time, but there will be no migration.

If the old object is still loaded with the old GUID, it will not be replaced.

Only when that object is missing, will the replacement GUID be recognised and the old object replaced with the new one, and the forward migration script run.

Barry.

[Sam Karli]

Absolutely.

My emphasis was rather on the fact that we have two objects having the same name and we don't see their GUIDs, so we have to be super care about which one is which one.

Especially when we are about to migrate stuff in a real project: this can lead to data loss.

Maybe a not-elegant solution is to have different names and rename the object back to the original name only after the successful migration.

[Barry Kelly]

---

@Sam Karli wrote:

Maybe a not-elegant solution is to have different names and rename the object back to the original name only after the successful migration.

---

You can have different names and this is essentially what Graphisoft has done for years with the version number in the object names.

If it doesn't migrate you will see the old version number (or the object will be missing).

If it does migrate successfully, you will just see it with the new version number.

I do this myself when migrating my objects.

For my migration object I will name it ... 'object_name-new'.

Then I will see this as I am testing if the migration goes well.

Once I am happy I will just rename that object back to the original name and then replace the old file with the new one in my library.

Barry.