I’ve been doing some CSV imports into Tinderbox. These files are exported from a relational database, and each record has many attributes defined in said database. I want to keep these but add prefixes, so I’ll know these attributes weren’t ones I created in Tinderbox. I’m currently doing this by adding the prefix in the CSV file for each column heading before I do my import—no issues with this piece. However, I often have columns that don’t have values in these data sets. Tinderbox is really good at looking at values and assigning an attribute data type based when there are existing data values. However, in my situation, Tinderbox sets the attribute to Boolean-Type because there are no values. I thought it would be nice to tell Tinderbox what data type to assign. For example, add text to the column heading with special characters e.g., #String-Type#, and then have the data type set.
If the above is not possible, what would be the most effective after-import process to automatically do this instead of manually doing it from the inspector? Would it be a stamp or agent?
I thought I’d provide some more context. Manually applying the data type probably won’t take that much time. I usually don’t build processes around edge cases, but since I’m in learning mode with Tinderbox, I have a mindset of trying to understand what is possible so that I can squirrel away these tricks and apply them more broadly down the road.
I had similar testing results. I could set suggested values and also default values but not type. The below set a boolean default value to true without issue for an existing attribute. I also did some variations trying to get type to work and noticed things worked with various syntaxes. e.g., with or without . or “” .
As has been noted, and as I realise the above omit to mention (on the to-do list!) is that Tinderbox can now create attribute via action code. That said, we still—as the user—have do decide:
what source columns should map to in Tinderbox and if new attrIbutes
what these should be named
what data type they should use
default values, suggested values etc.
Apart from simple exploratory tests, e.g. “Does anything import at all?” my approach is to ensure the correct (additional, if necessary) attributes are configured as needed before doing the main data import.
If the source if giving you helpful column names like TablA Pr_ea you might consider editing the heard row of the data to use your desired Tinderbox attribute name for each columns data as there is no import map process. If you didn’t make/don’t control the source the default header names are often unhelpful and using Tinderbox’s best guess at a Tinderbox-compliant guess is little better. 5 minutes work pre-import an save hours of frustration though the years of use of a document. You can always add a note (or an attribute description) recording the data source’s original column name.
No but you can make a list like “Price:number;SKU;string” which is a list of attributename+colon+datatype+semicolon items. Both are case-sensitive : the attribute name must conform to attribute naming rules and data type is always all-lowercase. There should be no line breaks between name:type pairs. Let’s assume we’ve made such a listing the $Text of a note. Now a stamp can make the attributes: