@rodrigoEscrol sorry for the delay in getting back to you.
I may be reaching the limits of my own understanding of Quick internals here, but I think you bring up an excellent point.
From what you are describing, the issue is not really that your custom cast is broken. It sounds like Quick is not calling the custom cast at all when the database value is NULL. So your cast never gets the chance to decide that NULL should become false on the CFML side.
I can also understand why Quick may behave this way intentionally. NULL and false are not always the same thing. NULL can mean “not set”, while false means “explicitly no”. So Quick may be trying to preserve that difference before the cast runs.
However, I agree with your general point that if a custom cast is defined, there is a good argument that the cast should be allowed to decide how NULL is handled. In your case, you want the database value to be S/N/NULL, but the CFML side to always behave like a pure boolean.
My practical recommendation would be:
-
If NULL should always mean false for this column, the cleanest solution is probably to fix that at the database level. Update existing NULL values to “N” and add a database default of “N” so the column does not return NULL anymore.
-
If you cannot change the database, you could create your own custom getter for the column, (e.g.
getFotosGrandes()) that will check for null and return false, like this:
function getFotosGrandes() {
var value = retrieveAttribute( "FotosGrandes" );
// if value is null or doesn't have a length, return false.
if ( isNull( value || !len( value ) {
return false;
}
return value;
}
- Since this original thread is older and Quick has changed quite a bit since then, I think this topic probably deserves a new thread. The core question would be something like: “Should custom casts in Quick be called for NULL database values?” That would let @elpete clarify whether the current behavior is intentional, configurable, or something they would consider changing.
I think your question is valid. I am just not 100% sure whether Quick’s current behavior is by design or whether there is a better built-in way to handle this.
Side note: I noticed in your cast you transform true into “S” instead of “Y”. I know in Spanish, “yes” is “si”. One recommendation I have is to take spoken language differences out of boolean data types. Instead of using a string value there, I recommend using a boolean datatype like “bit” if you’re using SQL Server. That way, the value becomes universally understood.