Instance of the same block have the same UUID

[alisajung]

I noticed that whenever a function block is deployed, it always has the same UUID. That means, if you create a data flow graph, distribute it, and then change some attributes of the blocks (e.g. Name or Thresholds), and then distribute the modified application, the modified block still has the same UUID as the previously deployed one. I don't think this is a good thing, wouldn't it be better if the UUIDs of blocks were unique for each instance of the block?

[Patagonicus]

That's intentional. Block UUIDs are assigned when blocks are created in Graphiti. However all Messages regarding blocks are sent as ApplicationSpecificMessages and the tupel App ID + Block ID is unique. I think this issue can be closed if you don't see a problem with this.

[Patagonicus]

Refarding modifying the App: I'd rather add a version field for the App itself if it is really needed to track this. Or tell the deployed app the last modified date of the source file or something.

[alisajung]

I created a new Class, BlockID, that holds both the UUID of the Block (which is the same for each instance of the block, but only appears once in every application) and the UUID of the Application the instance of the block is running in (which is the same for each block within the application, but different for every instance of the block).

[schnabeltrei]

BlockId can not be transmitted, as Json does not handle Objects as keys in Maps well. Changed the use of BlockID to a string, which should be equally unique. see commit 6d10d6a78fc559a2594052624d237fb09495384f

[Patagonicus]

I'm pretty sure Alisa fixed that (I think by calling something like allowComplexMapKeys on GsonBuilder or so). At least she got them transmitted correctly. I'll reopen this bug as I don't like the idea of sending Strings when we have a special class for this ID.

[alisajung]

Since I spent that much time creating and dealing with BlockID, I'm sure there is another fix for the problem than simply using Strings. I will look into that after the numerics test on tuesday. Are you sure you pulled all of my commits?

[schnabeltrei]

You did not adapt the tests, which made me assume it is broken (please keep the tests up to date and check whether they run properly) I will just reverse my changes and see what happens. ( reference: 6d10d6a78fc559a2594052624d237fb09495384f )

However my point about: "If we enable complexMapKeys we will get rather ugly Json" still stands. I do not think there is a workaround.

[Patagonicus]

While I agree that the tests should have been adapted you could have looked at the offending commit and/or asked why things are broken. At least reverting your changes should have been easy with GIT.

Regarding the ugly JSON: I think we can write a GSON adapter that transforms BlockIDs into Strings (appID + "-" + blockID or something), but we probably still need the flag for complex keys.

[schnabeltrei]

I do not disagree with that XD (I simply assumed BlockID was a quick fix for a small problem, that did not work properly as not even the tests were adapted, let alone the BlockID.toString() returning "blabla"...)

And yes git is awesome. I think we should write that adapter indeed, however I would go for maybe: appId + "+" + blockId, as UUIDs already contain lots of "-" :)

[alisajung]

Oh, I totally forgot about the "blablabla" thing, I will change that. And I'm pretty sure I already created a BlockAdapter for the GSON stuff, although I don't remember which package I put that one in.

[schnabeltrei]

I think Patagonicus is referring to writing one to completely transform BlockID into a String, probably one for ApplicationListResponse is needed. (Although if we return a String instead of an object in BlockIdAdapter.serialize it might work as well ?), or are you referring to another adapter? (otherwise the package would be module.message.infoReq)