topic Re: Migration again: (when) does FWM script run? in GDL

Migration again: (when) does FWM script run?

Sam Karli — Thu, 26 Sep 2024 10:56:50 GMT

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.

Re: Migration again: (when) does FWM script run?

Dominic Wyss — Wed, 24 Jan 2024 07:30:45 GMT

Hi Sam,
I had the same questions and issues. The crucial part is that in the migration table, "AutoMigration" is turned off. Only then are the migration scripts executed. Regarding the example script, you are right... it has quite a bit of boilerplate. Even simpler scripts work well. However, the most important thing is at the end, passing the current GUID of the new object with "setmigrationguid." Otherwise, the migration fails. This can also be used intentionally to make the migration fail by setting "setmigrationguid" to "".

!! only runs when AutoMigration is turned off in migration table !! !-- get value of deleted parameter if deleted_par_value("oldPar", _oldPar_val) then parameters newPar = _oldPar_val !-- just set value of new parameter parameters migrated = "yes" !-- most important: set to new guuid setmigrationguid "6DF48F44-A977-4A50-94E7-35084538DC4D" ! GUUID of the new object

HTH

Re: Migration again: (when) does FWM script run?

Sam Karli — Wed, 24 Jan 2024 08:57:21 GMT

Wow, success.

So, to summarize it, there are two possibilities of migrating:

Automigrate is ON: this way it is only needed to fill out the migration table BUT the Forward Migration Script doesn't run.
Automigrate is OFF: this way the Forward Migration Script runs BUT there must be a setmigrationguid command that actually changes the object.

PS now the only thing is to explore is the versioning of the object ie. the "second part" of the guid. As far as I remember ArchiCAD has two guids, the first being the same for, like, Door 26 and Door 27 and only the second one is different. How to migrate this way,

Re: Migration again: (when) does FWM script run?

Barry Kelly — Wed, 24 Jan 2024 09:21:49 GMT

@Sam Karli wrote:

PS now the only thing is to explore is the versioning of the object ie. the "second part" of the guid. As far as I remember ArchiCAD has two guids, the first being the same for, like, Door 26 and Door 27 and only the second one is different. How to migrate this way,

There is a sub-type GUID but that is not used in the migration.

That should stay constant - a door is a door.

The GUID you see in the migration table is unique for every object, and that is what you need to use.

I use the migration table to find the GUID of the new object as well as the old ones you want to migrate.

Just be sure to delete the new object GUID from the table list once you have it in the migration script.

Otherwise your objects will not migrate.

Barry.

Re: Migration again: (when) does FWM script run?

Peter Baksa — Mon, 05 Feb 2024 17:09:42 GMT

Hi,

the second part - revision ID - (shown in subtype hierarchy window) is not important (and not visible) to GDL.

Migration only happens when the main GUID is not in the loaded libraries. Same main ID, different revision ID is considered a match, the currently loaded .gsm is used without running migration script.

https://gdl.graphisoft.com/gdl-style-guide/library-part-format

Re: Migration again: (when) does FWM script run?

Sam Karli — Tue, 06 Feb 2024 11:40:19 GMT

That is rather sad.

That is because I'm thinking of systematically modifying objects in projects architects work already on by migrating.

Typical situation is as follows:

We have objects already placed
For (a part of) objects we want to change a parameter systematically, so
We unload the (existing) library, load up the "new" library, having a new version of the objects
This is the point we want to run FWM script to modify params etc.

For this, we have to have a new guid for the (same) libpart, which is not elegant.

(Yes, it is possible to change params manually, but it is prone to errors, time consuming, architects have to do this etc., so not preferred)

A concrete situation was as follows:
In AC25 or WC26, there were Shower Plates (already placed) in a project. These had two types:

Drain in the middle
Drain in the corner

Architects wanted a third option, drain having at the middle of one side, so I added xDrain and yDrain to enable them to place the drain anywhere.

So we wanted to change all the Shower plates that have Drain in, say, the middle of the plate but unchanged ones that have drains in the corner.

Thx.

Re: Migration again: (when) does FWM script run?

Peter Baksa — Tue, 27 Feb 2024 10:20:32 GMT

For this, we have to have a new guid for the (same) libpart, which is not elegant.

This is how migration is designed to work.

Placed objects store their parameter list and GUID of the script in the plan. The drawing refreshes by executing the script from the currently loaded library.

The new libpart in your case isn't the same, because it has two more parameters. If we would give the parameter list of the new shower to the old script, it could draw it differently, because it ignores the new parameters.

Re: Migration again: (when) does FWM script run?

Sam Karli — Fri, 01 Mar 2024 00:58:14 GMT

But when, for example, migrating current AC versions, what happens as, like, Door 26 and Door 27 have the same main ~~UUIDs~~ GUIDs ? For newer ArchiCADs the main ~~UUIDs~~ GUIDs stay the same but I think the migration occurs, and I don't think it's only based on different names and/or different parametrization (none is guaranteed to change).

Thx

Re: Migration again: (when) does FWM script run?

Barry Kelly — Fri, 01 Mar 2024 01:27:37 GMT

The name of the object can be different in each version.

If the GUID is the same in each version, there is no migration as such.

It is just loading the same object as it has the same GUID - it will just have the new name automatically.

Archicad does not load objects based on the name, only by the GUID.

If there are no changes, only minor changes to an object, or new features that only 'add' to the object, then there is no need to migrate, and the GSID can remain the same.

If you have two objects loaded (can be in the same of different libraries) with the same GSID (the objects can have different names), that is when you get a warning in the Library Manager that there are duplicated objects.

That is why you need to delete the old object from your library and it will simply get swapped for the new one (with the same GSID).

If parameters in the new object have been removed, new features added that will affect the existing object settings, or you need to force a parameter value change, then the object needs to be migrated to a new object with a new GSID.

In the migration script, you can control the setting of new and existing parameters.

You will have the new object in the library, but the old original one needs to be removed for the migration to happen.

When you load the library, if the object is missing Archicad can obviously not load it.

But Archicad also looks through all of the migration scripts to see if there is one that contains the now missing GSID and then swaps it for the new object with the new GSID.

If you don't remove the old object from the library, you will simply end up with two objects to chose from and no migration will occur.

Sometimes, new objects are just so different, it is not wise to migrate them.

In that case you can make the original object 'Obsolete'.

You will have bot the obsolete object and the new object in the library.

This means when placing a new object, it will not be seen in the selection settings - you will only see the new object.

But if you have an existing object in the plan already, you will still see the original object and its settings when you select it.

It took me quite a while to figure out how it all worked.

I am sure I am probably still missing things.

But I can now migrate my own library objects with the new settings or mark them as obsolete.

Barry.

Re: Migration again: (when) does FWM script run?

Lingwisyer — Fri, 01 Mar 2024 04:10:50 GMT

You can sort of force a uniform change in a parameter by deleting the relevant parameter, reloading the object, then adding the parameter back with it's new value.

but unchanged ones that have drains in the corner.

What do you mean by this?

Ling.

Re: Migration again: (when) does FWM script run?

Sam Karli — Tue, 09 Jul 2024 21:15:35 GMT

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

Re: Migration again: (when) does FWM script run?

Barry Kelly — Wed, 10 Jul 2024 00:33:22 GMT

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

Re: Migration again: (when) does FWM script run?

Sam Karli — Thu, 18 Jul 2024 12:24:02 GMT

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.

Re: Migration again: (when) does FWM script run?

Barry Kelly — Fri, 19 Jul 2024 02:54:33 GMT

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