In an effort for ZC to provide equivalent operation, a level of sanitization, and be able to better handle/address conditions such as an individual having the last name of null, a new "datatype" was introduced of stringIgnoreNull where a string that only contained the word null would be prepared for the database to be stored as a word and not as a null value. The problem is that there is no direct test for the presence of that "datatype" within the store software, but there is a way to test against the functions, not cause an error and determine the condition of the database and it's support of the datatype.
Testing for this aspect can be done by testing against a particularly formatted string that is identified as a string. If the result is of a particular format, then the "datatype" stringIgnoreNull is available for use. The thing is that cases where it is desirable to return the value of null only, then some up front testing should be performed where the review likely would be to validate that the entire content was only the word and not that it just contains the word somewhere within. Anyways, some thought consideration is needed.
Discovered this as an issue when I exported a database, imported that data, and then again exported it. In comparison between the two databases, I was able to identify that a products_description was cleared because the content had the word NULL in it. This is even though there was far more content than just the one word. So, yes it would be good to benefit from the sanitization where/when needed but to be able to apply the stringIgnoreNull type intelligently.
In an effort for ZC to provide equivalent operation, a level of sanitization, and be able to better handle/address conditions such as an individual having the last name of null, a new "datatype" was introduced of stringIgnoreNull where a string that only contained the word null would be prepared for the database to be stored as a word and not as a null value. The problem is that there is no direct test for the presence of that "datatype" within the store software, but there is a way to test against the functions, not cause an error and determine the condition of the database and it's support of the datatype.
Testing for this aspect can be done by testing against a particularly formatted string that is identified as a string. If the result is of a particular format, then the "datatype" stringIgnoreNull is available for use. The thing is that cases where it is desirable to return the value of null only, then some up front testing should be performed where the review likely would be to validate that the entire content was only the word and not that it just contains the word somewhere within. Anyways, some thought consideration is needed.
Discovered this as an issue when I exported a database, imported that data, and then again exported it. In comparison between the two databases, I was able to identify that a products_description was cleared because the content had the word NULL in it. This is even though there was far more content than just the one word. So, yes it would be good to benefit from the sanitization where/when needed but to be able to apply the stringIgnoreNull type intelligently.