Re: [Quickfix-developers] Re: empty tag
Brought to you by:
orenmnero
|
From: Alvin W. <AW...@FF...> - 2005-07-05 15:58:08
|
Oren,
I use the same code base to deal with multiple counterpaties. We want to
demoralize some fields and save them in our tables for future use. That
means I only need to retrieve the values and save to DB. So sometimes I do
not really care if it is Null or not for most of tags
Thanks
Alvin
"Oren Miller" <or...@qu...>
07/05/2005 11:45 AM
To: <qui...@li...>,
<qui...@li...>, "Alvin Wang"
<AW...@FF...>
cc:
bcc:
Subject: Re: [Quickfix-developers] Re: empty tag
The configuration setting ValidateFieldsHaveValues already exists.
Returning null is not really an option in the C++ api. I'm not really
sure if always having to check for null before using a field really saves
any trouble anyway. The engine is designed to catch the exception and
send an appropriate reject message if not present. Maybe I'm not
understanding your particular case, but I'm not really sure why you need
to trap that exception in the general case.
--oren
----- Original Message -----
From: Alvin Wang
To: Oren Miller ; qui...@li... ; qui...@li...
Sent: Tuesday, July 05, 2005 10:29 PM
Subject: Re: [Quickfix-developers] Re: empty tag
Oren,
if we can discuss this issue in a more broader scope, can QF have a
configuration to (dis)allow to handle "empty-tag" message received from
counterparty?
Also, can the message.getFiled() method return null if a tag does not
exist (or is empty)? rather than through a exception.
I have found catching this kind of exception is troublesome and I have to
wrap it in my own methods for each different data types.
Thanks
Alvin
Alvin Wang
07/05/2005 11:16 PM
To: "Oren Miller" <or...@qu...>
cc: qui...@li..., qui...@li...
Subject: Re: [Quickfix-developers] Re: empty tagLink
IMHO, can QF have a configuration for this behavior? Exception(strict) vs
Ignore(forgiving)...
Thanks
"Oren Miller" <or...@qu...>
Sent by: qui...@li...
07/05/2005 10:16 AM
To: "Alvin Wang" <AW...@FF...>
cc: <qui...@li...>,
<qui...@li...>
bcc:
Subject: Re: [Quickfix-developers] Re: empty tag
My concern is how to handle the situation where the field already exists.
If field 58 is set in the message, and I set it again with a field that
has an empty tag, what does this mean? Does it mean that I ignore the new
field and retain the old value? Or do I remove the old field from the
message completely. In which case setting a field with an empty tag is
the same behavior as calling removeField. Both of these behaviors feel a
little surprising to me. I'd be interested in hearing other opinions on
this.
--oren
----- Original Message -----
From: Alvin Wang
To: Oren Miller
Cc: qui...@li... ; qui...@li...
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag
Oren, I can understand where you are coming from. It makes total sense if
QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers
and the production may become disruptive.
Thanks
Alvin
"Oren Miller" <or...@qu...>
07/05/2005 10:00 AM
To: <qui...@li...>, <qui...@li...>, "Alvin Wang" <AW...@FF...>
cc:
bcc:
Subject: Re: empty tag
We could, although more likely I would throw a NoTagValue exception. I
don't much like the idea of having QF silently ignoring a field that the
developer would be expecting to go out in the message (much like I don't
like the current behavior). I can imagine the head scratching that would
go on if they added a field and then found it mysteriously absent in the
logs.
In either case if you have a field that might contain a blank value, I
would suggest checking it before adding it to a message.
--oren
----- Original Message -----
From: Alvin Wang
To: qui...@li... ; qui...@li...
Cc: Oren Miller
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag
HI
If I set a tag as below:
message.set(new Text(text));
and if the variable "text" is null. QF will include an empty tag 58. As a
result, some FIX engine (such as QF itself) on the other end will reject
the message. Can QF skip including empty tag?
Thanks
Alvin **********************************************************************
This e-mail message is intended solely for the use of the addressee. The
message may contain information that is privileged and confidential.
Disclosure to anyone other than the intended recipient is prohibited. If
you are not the intended recipient, please do not disseminate, distribute
or copy this communication, by e-mail or otherwise. Instead, please notify
us immediately by return e-mail (including the original message with your
reply) and then delete and discard all copies of the message. We have
taken precautions to minimize the risk of transmitting software viruses
but nevertheless advise you to carry out your own virus checks on any
attachment to this message. We accept no liability for any loss or damage
caused by software viruses.
**********************************************************************
|