We need to get a unique identifier for all related fix messages in quickfixj.
scenario: if B lies between A and C and forwards fix messages from A to C and vice versa, we need to get a unique Id for all related messages to cache them in B.
Is there a uniqueId for all fix messages as mentioned above? if yes, does getting that unique identifier same (eg: message.getString(int field)) for all message types, or getting it depends on message type?
Do you mean a unique identifier per Order, for example? If yes, then that would be 11/ClOrdID for a NewOrderSingle (and some other message types). But you'll have other identifiers for other message types, e.g. quotes, market data snapshots, ...
There is no global unique identifier per se, so you would need to make one up. For example a concatenation of SenderCompID and MsgSeqNum and SendingTime should be unique. If you are sure that you will not reset the sequence number intra-day you could probably even leave out the SendingTime.
Related
I'm about to LOAD some random data into Neo4j. Documentation says that the IDs must be unique. Does the data type of unique identifier matter? For e.g. can I have a unique string as an identifier instead of a (integer) number?
Yes, you can have unique Strings instead on numbers! afaik, any valid data type, even Point
I've set up receiving of Teams CallRecords into Splunk and now stuck in a process of understanding them. I thought that one CallRecord represents one unique Teams call (like Mr. A dialed Mr. B, Mr. B answered, they talked and eventually hung up - that's a CallRecord) and documentation suggests that it is so: "callRecord resource type represents a single peer-to-peer call or a group call between multiple participants", "id - String - Unique identifier for the call record. Read-only."
But what I see is many CallRecords with same id but different versions ("version" field). These records might have different DateTimes of start and end, different lastModifiedDateTime, some versions have null values of organizer* and participant* fields. I saw quantity of versions from 1 to 66.
So here are my questions:
Does the one CallRecord represent one unique conversation? If yes, what would be it's unique identificator? id+version? Then why there are records with same id, different versions and same other data except lastModifiedFateTime (so these records are roughly the same and it will result in double accounting in final report)? And why there are records with null fields of organizer*?
Does the set of all CallRecords with same id and different versions represent one call? If I merge all such records into one I get multivalue fields of startDateTime, endDateTime and other DateTimes - which values of them I need to use for accounting - min(startDateTime) and max(endDateTime) or what?
Maybe there is some deep dive Microsoft documentation on this versioning? Frankly, I've completely lost here.
I'm building a REST API which will serve information about statements stored in my Jena TDB.
It would be great if each statement has its unique ID so I can use this ID in GET request to retrieve information about particular statement. Is there something like that in Jena?
I know I can retrieve statement(s) by providing appropriate subject/predicate/object identifiers to model.listStatements method, but it would be quite ugly to add these parameters to API GET requests.
In RDF, a triple is defined by its subject, object and predicate. If you have two triples with the same S/P/O, it is really the same triple (value-equality, not instance equality). An RDF graph is a set of triples; if you add a triple twice, the set has only one instance. There is no triple id concept in RDF, and there isn't internally in TDB.
So you could use unique identifiers, say a string of length 4, for every S, every P and every O. Just save them all as key/value (id/resource, id/property) pairs. Then you will have a string of length 12 as unique identifier of your statement.
Even if a statements is deleted and added again, leading to a different id when tagging every statement with an id, this method will yield the same statement every time.
E. g. In Composition the element date has the data type dateTime.
<Composition xmlns="http://hl7.org/fhir">
...
<date value="[dateTime]"/><!-- 1..1 Composition editing time § -->
...
Is it with a Profile possible that the element date also adapts another data type, for instance the data type date?
See http://hl7.org/fhir/2015May/structuredefinition.html#6.17.5.2
Under the bullet "In practice..." the specification states "the list of types for an element must be the same or a subset of the list of types for the same element in the base structure".
So, no, new types may not be introduced. In general, a Profile (StructureDefinition) can only further restrict the use/content of a resource. It may not loosen the standard.
Chris is correct - the type cannot change and new types cannot be added. So if the specification says dateTime, you can't use "string" instead. However, in this specific circumstance, you can communicate "just date" within dateTime. And you can assert constraints against the type. So in theory, you could assert a length constraint of 10 characters on dateTime, essentially making it a date. As well, there's no requirement in FHIR that you store everything that's sent to you. So it's legitimate to throw away any time information that is sent to you (see http://hl7.org/fhir/2015May/updates.html for more information).
As a rule, stripping the time would be better than outright rejecting instances that contain a time. However, even that option is going to be seen as unexpected/undesirable by many communication partners.
Internally, my website stores Users in a database indexed by an integer primary key.
However, I'd like to associate Users with a number of unique, difficult-to-guess identifiers that will be each used in various circumstance. Examples:
One for a user profile URL: So a User can be found and displayed by a URL that does not include their actual primary key, preventing the profiles from being scraped.
One for a no-login email unsubscribe form: So a user can change their email preferences by clicking through a link in the email without having to login, preventing other people from being able to easily guess the URL and tamper with their email preferences.
As I see it, the key characteristics I'll need for these identifiers is that they are not easily guessed, that they are unique, and that knowing the key or identifier will not make it easy to find the other.
In light of that, I was thinking about using SecureRandom::urlsafe_base64 to generate multiple random identifiers whenever a new user is created, one for each purpose. As they are random, I would need to do database checks before insertion in order to guarantee uniqueness.
Could anyone provide a sanity check and confirm that this is a reasonable approach?
The method you are using is using a secure random generator, so guessing the next URL even knowing one of them will be hard. When generating random sequences, this is a key aspect to keep in mind: non-secure random generators can become predictable, and having one value can help predict what the next one would be. You are probably OK on this one.
Also, urlsafe_base64 says in its documentation that the default random length is 16 bytes. This gives you 816 different possible values (2.81474977 × 1014). This is not a huge number. For example, it means that a scraper doing 10.000 request a second will be able to try all possible identifiers in about 900 years. It seems acceptable for now, but computers are becoming faster and faster, and depending on the scale of your application this could be a problem in the future. Just making the first parameter bigger can solve this issue though.
Lastly, something that you should definitely consider: the possibility for your database to be leaked. Even if your identifiers are bullet proof, your database might not be and an attacker might be able to get a list of all identifiers. You should definitely hash the identifiers in the database with a secure hashing algorithm (with appropriate salts, the same you would do for a password). Just to give you an idea on how important this is, with a recent GPU, SHA-1 can be brute forced at a rate of 350.000.000 tries per second. A 16 bytes key (the default for the method you are using) hashed using SHA-1 would be guessed in about 9 days.
In summary: the algorithm is good enough, but increase the length of keys and hash them in the database.
Because the generated ids will not be related to any other data, they are going to be very hard (impossible) to guess. To quickly validate there uniqueness and find users, you'll have to index them in the DB.
You'll also need to write a function that returns a unique id checking the uniqueness, something like:
def generate_id(field_name)
found = false
while not found
rnd = SecureRandom.urlsafe_base64
found = User.exists?(field_name: rnd)
end
rnd
end
Last security check, try to check the correspondance between an identifier and the user information before doing any changes, at least the email.
That said, it seems a good approach to me.