Imported from previous forum
I am often confronted with the opinion: “Mandatory fields are never nullable by definition”.
I would like to know, where is this defined?
The FAST Specification defines only a positive list of all cases in which nullable types have to be used. There are no information about forbidden cases.
The FAST Protocol - Transfer Encoding Specification - gives some information about the sense of Null values. It also does not forbid any combinations of nullable data types and mandatory presence.
Are there information that explicitly forbid such combinations?
Reason of question & example:
I become aware of a template defintion, where a field with a nullable supporting integer type is used differently:
a) optional - no operator
b) mandatory - no operator
a) is explicitly defined within the FAST specification. It is clear, that the type have to support Null Values.
b) is not explicitly defined within the spec.
I think, because of the presence “mandatory”, the transfered values of this field would never be a null value. So, is the property of null support really a problem in this case???
What do you think?
Nullability is defined in section 10.4 of the FAST Specification 1.1:
"10.4 Nullability
Each field has a type that has a nullability property. If a type is nullable, there is a special representation of a NULL value. When a type is non-nullable, no representation for NULL is reserved. All nullable types are constructed in such a way that NULL is represented as a 7-bit entity value where all bits are zero. It is represented as 0x80 when stop bit encoded.
Unless explicitly specified, non-nullable representations are used."
A mandatory field always has a value logically and it wouldn’t make sense to use the notion of NULL in that case. (I say logically because a value is not always physically present in the stream if for example a copy operator is in use.)
/David
I am often confronted with the opinion: “Mandatory fields are never
nullable by definition”.I would like to know, where is this defined?
The FAST Specification defines only a positive list of all cases in
which nullable types have to be used. There are no information about
forbidden cases. The FAST Protocol - Transfer Encoding Specification -
gives some information about the sense of Null values. It also does not
forbid any combinations of nullable data types and mandatory presence.Are there information that explicitly forbid such combinations?
Reason of question & example: I become aware of a template defintion,
where a field with a nullable supporting integer type is used
differently:
a) optional - no operator
b) mandatory - no operatorc) is explicitly defined within the FAST specification. It is clear,
that the type have to support Null Values.d) is not explicitly defined within the spec. I think, because of the
presence “mandatory”, the transfered values of this field would never
be a null value. So, is the property of null support really a problem
in this case???What do you think?
Hi David,
thank you for reply.
Yes, I agree. A nullable type for a mandatory field is not useful, because the null value is never used. That’s clear.
In respect to my example, the field with the nullable type is used with different presence definitions and without any operator.
I have asked my question, because a lot of people tell me massively:
- nullable types for mandatory fields are not applicable at all
- nullable types for mandatory fields are forbidden
- nullable types does not work for mandatory fields
- etc, etc
…and I can’t derive these opinions from the FAST spec.
I think, there is a difference between “not useful” and “not possible”.
Heiko
Nullability is defined in section 10.4 of the FAST Specification 1.1:
"10.4 Nullability Each field has a type that has a nullability property.
If a type is nullable, there is a special representation of a NULL
value. When a type is non-nullable, no representation for NULL is
reserved. All nullable types are constructed in such a way that NULL is
represented as a 7-bit entity value where all bits are zero. It is
represented as 0x80 when stop bit encoded.Unless explicitly specified, non-nullable representations are used."
A mandatory field always has a value logically and it wouldn’t make
sense to use the notion of NULL in that case. (I say logically because a
value is not always physically present in the stream if for example a
copy operator is in use.)/David
I am often confronted with the opinion: “Mandatory fields are never
nullable by definition”.I would like to know, where is this defined?
The FAST Specification defines only a positive list of all cases in
which nullable types have to be used. There are no information about
forbidden cases. The FAST Protocol - Transfer Encoding Specification -
gives some information about the sense of Null values. It also does
not forbid any combinations of nullable data types and mandatory
presence.Are there information that explicitly forbid such combinations?
Reason of question & example: I become aware of a template defintion,
where a field with a nullable supporting integer type is used
differently:
a) optional - no operator
b) mandatory - no operatorc) is explicitly defined within the FAST specification. It is clear,
that the type have to support Null Values.d) is not explicitly defined within the spec. I think, because of the
presence “mandatory”, the transfered values of this field would
never be a null value. So, is the property of null support really a
problem in this case???What do you think?
In the FAST Specification 1.1, the terms “mandatory” and “optional” refers to concepts in the template definition. So if you create a FAST 1.1 template definition and specifies that a field is mandatory, it must always be encoded in a non-nullable representation or a decoder based on the same template definition wouldn’t work. This is as defined in the specification.
Your perception of the nullability of a field outside the FAST encoding layer is another thing and there the FAST specification obviously has nothing to say. If you for example treat a field as mandatory in your application but declare the field to be optional in the template, you’re free to do so, though I’d try to avoid it.
/David
Hi David,
thank you for reply.
Yes, I agree. A nullable type for a mandatory field is not useful,
because the null value is never used. That’s clear.In respect to my example, the field with the nullable type is used with
different presence definitions and without any operator.I have asked my question, because a lot of people tell me massively:
- nullable types for mandatory fields are not applicable at all
- nullable types for mandatory fields are forbidden
- nullable types does not work for mandatory fields
- etc, etc
…and I can’t derive these opinions from the FAST spec. I think, there
is a difference between “not useful” and “not possible”.Heiko
Nullability is defined in section 10.4 of the FAST Specification 1.1:
"10.4 Nullability Each field has a type that has a nullability
property. If a type is nullable, there is a special representation of
a NULL value. When a type is non-nullable, no representation for NULL
is reserved. All nullable types are constructed in such a way that
NULL is represented as a 7-bit entity value where all bits are zero.
It is represented as 0x80 when stop bit encoded.Unless explicitly specified, non-nullable representations are used."
A mandatory field always has a value logically and it wouldn’t make
sense to use the notion of NULL in that case. (I say logically because
a value is not always physically present in the stream if for example
a copy operator is in use.)/David
I am often confronted with the opinion: “Mandatory fields are never
nullable by definition”.I would like to know, where is this defined?
The FAST Specification defines only a positive list of all cases in
which nullable types have to be used. There are no information about
forbidden cases. The FAST Protocol - Transfer Encoding Specification
- gives some information about the sense of Null values. It also
does not forbid any combinations of nullable data types and
mandatory presence.Are there information that explicitly forbid such combinations?
Reason of question & example: I become aware of a template
defintion, where a field with a nullable supporting integer type is
used differently:
a) optional - no operator
b) mandatory - no operatorc) is explicitly defined within the FAST specification. It is clear,
that the type have to support Null Values.d) is not explicitly defined within the spec. I think, because of
the presence “mandatory”, the transfered values of this field
would never be a null value. So, is the property of null support
really a problem in this case???What do you think?