Have you tried "jobbing" the routine from the CSP?

It is a best data management practice to add restrictions to fields if they have them. So adding the maxlen is "recommended"

Adding the maxlen won't result in wasted storage since storage is not reserved based on field definitions. If that were the case, in your particular scenario, you'd be actually saving storage since all string fields are defaulted to maxlen = 50 if you don't specify a value. 

Maybe I'm missing something, but, beyond how nulls are treated, if you want parent to be unique within this definition you must define a unique index on parent (alone). The index you have defined only guarantees that the combination (parent, name) will be unique.

Even if you declare the property as required it wouldn't still solve the uniqueness requirement. 

You need to use HyperEvents to accomplish what you want. Use #server or #call. Although if I'm following your use case #server is the right one. In the corresponding javascript function you'll have code similar to

myfunction() {

...

var myvar = #server(mycachemethod());

//check myvar value

// return true or false based value

}

Guessing a typo(copy paste from SetQualifiers?) in the documentation. It should say "...otherwise it gets the default qualifiers for this namespace."

Journal files are also exposed as SQL (readonly) tables. In theory, you could write SQL statements to search/filter. 

Few options without knowing much about current setup and the use case (eg. how much involvement you want to have in the process)

• Synchronizing(shadow) between the 2 instances - Global export/import
• Global mapping from one instance to another
  • You could merge global from source to target
•  File transfer (traditional ETL) and manipulating the global directly (risky but doable) 

Also, any indices on such field would need to be rebuild. Indices on %String properties are expected to start with an empty space thus your queries using these indices won't return any existing (non-updated) rows.