Added AllowUnknownFieldValues and AllowUnknownMsgFields configuration… #543
Conversation
|
|
peto268
force-pushed
the
relaxed_validation
branch
from
cfa7f4e
to
361bfa0
Compare
peto268
force-pushed
the
relaxed_validation
branch
from
361bfa0
to
1517524
Compare
|
Added one more exclude to the CheckValidTagNumber method so it wont throw an exception even for fields that aren't even defined in the dictionary. |
|
Has this pull request been abandoned? |
|
No, I'm just knee-deep in an unrelated project. I tend to hit QF/n in fits
and starts.
…On Mon, Sep 23, 2019 at 7:37 PM Michael B. Murray ***@***.***> wrote:
Has this pull request been abandoned?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#543?email_source=notifications&email_token=AABZ52GVKR22B7OZQW7ASU3QLFOLLA5CNFSM4INV7PV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7MVVSA#issuecomment-534338248>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABZ52ARUIFNO2IT5CTADKLQLFOLLANCNFSM4INV7PVQ>
.
--
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com
|
peto268
force-pushed
the
relaxed_validation
branch
from
1517524
to
a0ea7da
Compare
Added by connamara#543 submission, but there's no need or precedent for it.
...because that would break group parsing. (Parser would not be able to know when the group ends!) connamara#430 connamara#543
|
I adapted this fix in #577. I removed support for AllowUnknownFieldValues, because there's no precedent for it and it's not really needed. (The issues it addresses could be solved by simply editing the DD.) |
|
I would like to add my voice to the request to re-add support for AllowUnknownFieldValues. Whilst its true that a similar result could be achieved by modifying the DataDictionary to remove the enums completely, this overlooks the fact that applications may be using the dictionary for other pruposes - and it is useful to know if a field value falls into the known set or is for an unknown value. The DD is also useful for documenting the expected values (but still acknowledging that unknown values can be accepted) |
|
The reason why I've added it in the first place is that when you are integrating with a party that tends to use a lot of customization on top of vanilla FIX spec, you can end up doing a lot of DD tweaks just to make quickfixn happy and not fail on deserialisation. Even for fields / values that you don't really care about. Yes, it might be a precedent, but a useful one. |
|
I agree, we have the same situation. Surely we don't need every enhancement to come from the Java implementation before it can be considered for quickfix/n?
…________________________________
From: Peter Mihalik <notifications@github.com>
Sent: Monday, May 25, 2020 10:51:12 AM
To: connamara/quickfixn <quickfixn@noreply.github.com>
Cc: roblugt <roblugt@elcel.com>; Comment <comment@noreply.github.com>
Subject: Re: [connamara/quickfixn] Added AllowUnknownFieldValues and AllowUnknownMsgFields configuration… (#543)
The reason why I've added it in the first place is that when you are integrating with a party that tends to use a lot of customization on top of vanilla FIX spec, you can end up doing a lot of DD tweaks just to make quickfixn happy and not fail on deserialisation. Even for fields / values that you don't really care about. Yes, it might be a precedent, but a useful one.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fconnamara%2Fquickfixn%2Fpull%2F543%23issuecomment-633486856&data=02%7C01%7C%7Ca4b51210762a4bfbd42908d800912955%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259970739955325&sdata=Wd%2FJW3ep3KfY9k2H08oJF4lLDUkeRmdqmDkfXBWhJSE%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FAFTKQRNTV2FZJBZEAYKBEV3RTI5RBANCNFSM4INV7PVQ&data=02%7C01%7C%7Ca4b51210762a4bfbd42908d800912955%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259970739965304&sdata=SdDtnvsmmKCKp5l0Vi9HoHqg8ZaUIiXDmaEt514HCx4%3D&reserved=0>.
|
|
New features add code complexity and can contribute to future maintenance, so I do tend to scrutinize them and avoid ones that don't seem crucial. Precedent by C++ and Java makes the case stronger, since we don't want the ports to differ greatly. You have made a decent case, though. Let me bounce it off my colleagues. |
… settings.
This should resolve #430