Renaming key attributes without losing values

Yes, those sound like familiar reasons for wanting to rename a user attribute. If one is formalizing as one goes along, then renaming may be more common than if one knows it is critical to do a lot of planning at the outset.

I been happily assuming that renaming a user attribute in Tinderbox involved editing the box in the inspector. I’ve gotten away with that a couple of times without losing data.

That assumption seemed natural because that is similar to how one changes a “field” name in databases that are known to require more structure up-front, among them Microsoft Access on Windows and Tap Forms on the Mac (probably FileMaker too, though I no longer have a working copy). Changing a column header in a spreadsheet or in an app like OmniOutliner is also straightforward. (I say straightforward for the user, not necessarily the developer!)

It’s good to know the safe workaround of copying the values to a new attribute, and deleting the old attribute, though it made me think of what one had to do in dBASE under DOS, back in the day.:slight_smile:

1 Like

Perhaps also have an explicit “Rename” command in the gear menu in the attributes inspector? Click “Rename”, the existing name gets highlighted. Type a new name. Press Return. The name change is applied. That is consistent with how note renaming works. Clear and consistent interface controls are helpful.

1 Like

This would make sense from my POV as well. The under-the-hood coding doesn’t seem as if it would be too complex, though that’s from a layman’s perspective. It would add flexibility if and when people wanted to do this. And it would be a protection against data loss, if someone renamed an attribute and then was surprised to learn that the values didn’t survive.

So if it’s doable at a reasonable coding cost, I would vote for it.

A word of warning to anyone following @eastgate’s procedure above: make sure you delete the “temporary agent” once you’ve finished or you won’t be able to alter the renamed attribute’s data value, as the agent will reset it back again (just discovered through hard experience!). For example, if your attribute is a list it won’t accept any additions. They’ll show up as you type them into the key attribute field, but will disappear when you close the note.

1 Like

I’ve updated my aTbRef note on Renaming an attribute to reflect this discussion. This is the situation as at v7.1.0.

If you transfer values from $A to $B then you will also need to update any $KeyAttributes values that referred to $A. This is in addition to action code in rules, agent action etc.

The overall process is very simple, the more ornate your document (e.g. lots of action code) the more tidying ip of agent values you’ll need to do. I don’t see an easy way to fully automate that; this isn’t a programming IDE.

Yes, good point.

Here’s another way you could build that protection into the agent. Let’s say it’s changing the value of $NewAttribute, based on the existing $OldAttribute. If you have the agent’s action set up as:

$NewAttribute|=$OldAttribute, then it will change the value only if it’s not already set. That |= operator adds the value if it’s empty but doesn’t over-write anything that’s already there.

Just one more approach. But deleting it after the one-time use does the job as well.

Be careful if you use prototypes to seed attribute values. If you use an agent to search for $OldAttribute that will match notes that inherit their value - and which you don’t want to change. My revised article on renaming/replacing attributes discusses this here (to save writing it all out here again).

TL;DR - don’t overlook hasLocalValue() :wink: