[BUG-15347] ObjectWrapper modification

Dears,
I am currently using the 8.0.5 release.
After the upgrade from the 8.0.4, I noticed a change in the manipulation of an ObjectWrapper instance.
For example:
the code below explains what I found: the param parameter is an ObjectWrapper

# Configure additional properties
param.Username 	= userName
param.Timestamp = fer.util.date.dateToSqlString(fer.util.date.getTimestampUtc())

I try to set the Username and Timestamp properties, but they did not change.
The above code run inside a library in Project Library.

Any idea of this strange behavior?
Thank you.

I did another test and the result is still unexpected.
I created a simple function, that assigns a property value to an object:

> def fnc(obj, key, value):
> 	system.perspective.print('key %s' % key)
> 	system.perspective.print('value %s' % value)
> 	system.perspective.print('id %s' % id(obj))
> 	
> 	#setattr(obj, key, value)
> 	execStr = 'obj.%s = "%s"' % (key, value)
> 	exec(execStr)
> 	
> 	system.perspective.print('obj %s' % obj)
> 	system.perspective.print('id %s' % id(obj))
> 	
> 	return obj

The function is called in a button ActionPerformed action, by:

	self.view.custom.tree = fer.provaLib.fnc(obj=self.view.custom.tree
										, key=self.getSibling("TextField").props.text
										, value=self.getSibling("TextField_0").props.text)

The result is again an object with the same structure, without the expected new property-value pair.

How can I solve this issue?
Please consider I developed many libraries with that logic and they have worked, before the 8.0.5 upgrade.

Let me know, thank you.
Andrea

@PGriffith

Probably related to the same changes causing this: [BUG] tolist() broken in 8.0.5

Do you need further information to fix it?
Let me know.

On the ActionPerformed of the same button, the direct assignment of a new property, as
self.view.custom.tree.test = 'test', works fine.

There’s something a bit weird here, definitely. We’ve got our defect analysts working on isolating the issue - it’s fairly easy to reproduce.

With the way that the function is called, it should work if you change:

self.view.custom.tree = fer.provaLib.fnc(obj=self.view.custom.tree
										, key=self.getSibling("TextField").props.text
										, value=self.getSibling("TextField_0").props.text)

to just:

fer.provaLib.fnc(obj=self.view.custom.tree
					, key=self.getSibling("TextField").props.text
					, value=self.getSibling("TextField_0").props.text)

Since the fnc() function is directly editing the object passed in. While this shouldn’t be an issue and is a bug that will be fixed, the workaround is to just not re-assign the object to be equal to itself.

Thank you all.
Let me know (as soon as possible :grinning:) when the bug will be fixed.
Unfortunately this gateway is in production and I need to understand which workaround to take.

Bye,
Andrea

Just to inform you that, in the example above, also the method obj.update({key: value}) and the syntax obj[key] = value do not modify the object obj.

Any workaround to alternatively modify the object?

All three of the methods there should have worked in 8.0.5 and shouldn’t need a workaround. At this point you’d probably have better luck contacting support so they can take a look and see if there’s something else that is missing from the script.

Solved from my side: I created a custom wrapper class.
I am looking forward to seeing your fixes.

Dears,

Any news about this issue? I notice the property assignment of an ObjectWrapper does not work (from 8.0.5 release and above) in the gateway scope (instead it works on client side).

Thank you.
Andrea

That doesn’t make any sense - there is no “client” side in Perspective (your scripts are still running on the gateway in a Perspective session) - can you define what you mean by client and gateway?

Also, we’ve identified the root of the problem, but don’t have an ETA on a fix. Basically, mutating the object/array wrapper objects correctly passes those mutations back to the root property tree - but does not update the mutable object you’re actually currently accessing. That’s why Oscar’s workaround above worked - if you don’t reassign the object directly back to the tree, then your value changes go through correctly.

Making the wrapper objects less co-dependent is probably the fix, but it’s not yet actively being worked on.