It should be safe to edit manually as long as you are not changing the piece numbers or changing the order around.  Simply changing the property name within  <Value>...</Value> of the storage definition should be fine if it is no longer used at all.  In our case, we have had instances in the past where we needed to change a property name and rather than creating a new property and migrating the data it proved to be safe and much more efficient to change the property name in both the property definition and the storage definition (as well as all of the places in the source code which refer to it).  The nice thing about this approach is that we've been able to simply do a Find/Replace in all of the source code and carefully review the diffs before submitting.  

If others are aware of gotcha's when changing the storage definition Value, I would be interested in hearing them.

as Vivian explained, you can delete the property definition and then change the name in the storage definition to make it clear that that slot should be ignored.  This of course should be done while keeping versions of everything in source control so that the reason for the change is documented and discoverable in the future should someone need to understand why the property was removed.  

Thanks for quick fix @Evgeny Shvarov!!  Also, thanks for the details that some types are not supported, that is good to know.  At this point I think I am good with letting it take it's best guess and then editing the class afterwards if needed.  With SQL LOAD coming hopefully there will be less need to one-off utilities that do this but I am thankful that it was available for what I needed this week!!

Wow - this looks like it is going to be an incredibly helpful feature!!  Thank you for pointing out the new docs on it :)

Partially answered my own question ... if I edit the auto-generated class' When property and set it to %Library.DateTime, I can then call the generated Import() classmethod of the auto-generated class and import will succeed.  So I am able to push forward ... is this the intended path to do this?  

Should I create an issue for the DateTime column to be property set as a DateTime object and not a Date object?  

Brilliant!!  Thank you @Sergey Mikhailenko  and @Sergei Shutov    :)

Don't worry about it - I have been writing ObjectScript code for 18 years and I had no idea about this method - I have always done it the way you did in your example :)  Thanks for asking the question so I could learn something new as well!

This looks like an excellent resource and I hadn't heard of it before.  Thank you so much for sharing!

@Guillaume Rongier - an interesting (and indeed radical) take on this ;)  I agree that broader use of Python will allow gaps and new best practices to be identified more quickly, to the benefit of all.  Your suggestion of not needing to use [language = python] is thought-provoking ... have you logged an enhancement to allow a descriptor at the class level which will allow python to be assumed across the entire class without requiring the python language to be specified in each method?  

I am generally quite conservative in nature, but your 'liberal' ideas are indeed thought provoking ;) 

""My aim is to get DC members who a really fond of some particular aspect of ObjectScript, or Adapters, or Devices, or IRIS HL7 and IRIS FHIR to create cheat sheets which I will collect into one volume and have them styled in ISC colours and logo's and add them to the ISC Learning, Documentation, Global Masters repertoire"  

I really love this idea!!  I know that @Michael Breen is also playing with ideas of how to crowd-source the simplification of ObjectScript reference resources to make it easier for new people to ramp up with the technology.
 

agreed!!!