|
General Q/A
< Previous Next >
re: Suggestion: mountains of IDs
Muhammad Kashif Awan / Kolachi Advanced Technologies
7 May 2004 5:23AM ET Hi,
I agree with the latter proposal but with some apprehension.
I think having ids in a repeating group is not a wise idea. Firstly these ids are company or implementation specific which are shielded from the connecting counter party. It would not make any sense to expose them in the message.
Secondly. this will consume extra space in the message, not to mention processing/logging overheads and I dont think that the cost-benefit ratio warrants a change towards it.
I do like the idea about the Globally Unique Identifiers as order ids. But in order to accomplish this, every engine would have to ensure that it is generating that identifier properly. The only problem is the executing party will have no easy way of determining the fact that this identifier is in fact globally unique. Relying on other ppl not to committ mistakes is in itself a mistake.
Kashif Awan,
kashif.awan@kolachi.net.
Manager Electronic Connectivity,
Kolachi Advanced Technologies.
www.kolachi.com.
> I'd like to add a couple of points to the ideas raised. First, I agree that walking a tree (find order A, then find the order id that it replaces, then find that replaced order, find the order id it replaces...and so on) to find the complete history of an order is an unwelcome chore when supporting FIX.
>
> By adding a repeating group of every order id this would be helpful in that you can immediately get to the nth order by looking for the nth member of the repeating group.
>
> I'd modify this proposal slightly by adding in a new datatype of uniqueidentifier which would then be used in as for the order id. The benefit of this is that by having genuinely unique order ids across sessions, clients, engines, days (whatever) the process of searching databases and log files for order ids would be much simpler. The order id would then be generated using a standard tool (such as CoCreateGuid in the windows OLE32.DLL).
>
>
> This would make order ids not human readable (such as 32EEAEE2F42248de85E71185926C9E0B) but genuinely unique, without requiring any centralisation of order id assignment.
>
> For more about how/what a guid is have a look at www.dsps.net/uuid.html or http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt
>
>
>
re: Suggestion: mountains of IDs
Muhammad Kashif Awan / Kolachi Advanced Technologies 7 May 2004 5:23AM ET
|
