This question already has answers here:
How can I get the current time in Cosmos DB
(2 answers)
Closed 4 days ago.
This post was edited and submitted for review 3 days ago and failed to reopen the post:
Original close reason(s) were not resolved
Is it possible to create a new item and set a field to the current time - as set on the server, in Cosmos DB?
I'm looking for something similar to INSERT INTO t VALUES (NOW()); in SQL.
I'd like to avoid asserting that the client time is correctly synced.
Update: To clarify, I don't mean GetCurrentDateTime().
I want to set the value of a custom field to the current server time.
e.g. {"started": "<NOW>"}
Can anyone share the code (in C# or Python, for example) that can be used?
A call to GetCurrentDateTime() will return current timestamp, which you can then store in a property of your new document. You would retrieve this via a SELECT. You'd then have to use a language-specific SDK call to write your document to your collection. Note that there is no INSERT statement in Cosmos DB's SQL dialect - it has to be done via SDK (or low-level API) call.
Also note that _ts will be automatically set to the exact time (in clock ticks) that the document is saved/updated. This will be the exact time the document was written. You could then save this value somewhere, upon first creating your document, to preserve original creation timestamp.
See here for more info on all date/time functions.
Related
This question already has answers here:
Does updating one field will download the whole document from the database or just update local version?
(1 answer)
Only retrieve changed document field
(1 answer)
Closed 2 years ago.
I have a question about the bandwidth / data usage of a Firestore listener.
I know Firestore will only give the updated documents once it's listening.
Let's say a single document is 0.3 mb. If it gets updated frequently, does the listener has to download the document (0.3 mb) every time or will it only download the "new/updated" data.
This would make a difference for the end-user who is maybe using 4g.
I use Flutter in combination with Firestore.
Thanks!
Every time a document is updated from an active listener, the entire contents of the document are transferred with each update. It does not transfer only the fields that changed.
This question already has answers here:
Document Updates - Do updates with no changes still cost 1 write?
(2 answers)
Closed 2 years ago.
Im trying to find out how firebase is billing write operations. In the billings documentation I could not find a clear definition of when a write is counted. Lets say I run a set query with the exact same data of the original documen, such that the document won't be affected, will this be billed as a write operation?
When I run my query with the console open nothing happens, and i was just wondering if these writes do also count.
When you write data, the server doesn't check if the data you write is the same as what already exist. Instead: it writes the data you provide. Hence: writing the same data is still counted as a write operation.
I find it easiest to understand the billing for Firestore by thinking of it as reads from/writes to a disk. When you tell a disk to write a file, it writes that file.
According to the Firebase - Firestore documentation, snapshotListeners provides all of the available records when we enabled the listener based on our query.
Firestore documentation:
The first query snapshot contains added events for all existing documents that match the query. This is because you're getting a set of changes that bring your query snapshot current with the initial state of the query. This allows you, for instance, to directly populate your UI from the changes you receive in the first query snapshot, without needing to add special logic for handling the initial state.
As far as I understood, it's not possible to disable this feature but there are some workarounds.
My question is if this behavior counts as one read for every record received during the first initialization or not?
My question is if this behavior counts as one read for every record
received during the first initialization or not?
The answer is yes: the "initial state of the query" implies that all documents corresponding to the query are read.
However, as explained in the documentation:
The initial state can come from the server directly, or from a local
cache. If there is state available in a local cache, the query
snapshot will be initially populated with the cached data.
If the initial state comes from a local cache (See offline data persistence), it will not count for any read.
This question already has an answer here:
How to generate unique DICOM UID?
(1 answer)
Closed 4 years ago.
I am a newbie to the world of DICOM, and I would like to send a modified DICOM file (created from a copy of a DICOM queried from a PACS server), back to the same server, as a new series for the same patient+study.
The modified DICOM would be a new single series, and I increment the last subnumber by +1. I do the same for the SOPUID. However, I am worried about the posibility of a new series being added in the same SUID getting added in the meantime and being rejected.
What is the accepted way of numbering when sending a new DICOM Image to a PACS server? Is it enough to increment SOPUID and SUID?
Creator must guarantee the global uniqueness of any UID value they generate. Incrementing an existing UID by 1 is by no means sufficient.
Basically the primary way of creating UID-s is to register a UID prefix for your organisation and then issue unique UID-s under that prefix, where you guarantee the uniqueness yourself by any means you see fit. The process is described in the DICOM standard here.
Another way proposed by the standard itself is to generate a UUID and convert that value to a single integer, to which you add a 2.25. prefix. This method is described in the DICOM standard also. This would generate a UID such as 2.25.34528018848038895355275102816408995430, which should be unique with sufficient reliability.
This question already has an answer here:
How to create auto incremented key in Firebase?
(1 answer)
Closed 2 months ago.
How can I get next key value (User03) continue from last recent key (User02) like image below:
To know the next key in this sequence, you will need to first load all the current keys.
This is one of the many reasons Firebase recommends against using arrays, since such an operation doesn't scale well, and will only work while the user is connected to the database. I recommend reading best practices for arrays in Firebase and what are Firebase push IDs.