Discussing the best way to model temperature data in Sanity.io
39 repliesLast updated: Jan 8, 2023
Is it possible for an update to a document in studio to create / update a different and separate (but related) document in the same dataset? Like a trigger-stored procedure type thing?
You will have to be a little more specific. Do you mean that both documents have the same field and you want to make them the same if either is changed? Is there a reason you would not use a reference?
Let's say I'm recording historical temperatures of various places worldwide. As I get reading for a particular place or city, I would update the document to reflect the current average temperature at that moment. I want the ability to go back and see what the average temperature was at a certain point in the past. How would I model that?
Well, just create a document with the timestamp, reading, and city. The current temperature would simply be the temperature with the highest/latest timestamp and where the city matches--a pretty simple GROQ query. Each reading would be one document. Sanity probably isn't the best tool to model this type of data, though, where you have a very, very high number of documents like this.
Ok. Is there an internal field for the timestamp that I could use?
_updatedAt and _createdAt maybe.
At its core, a document is a JSON-object that has a unique _id, timestamps (_createdAt, _updatedAt) and revision-marker _rev.https://www.sanity.io/docs/geopoint-type geopoint is cool if you need to map the cities
Ok, thanks! I'll see if I can make work with these fields
Should be super easy. Do you want me to mock up something for you?
Sure! But something very basic that works, so that I can grasp the concept and modify it if necessary
How many cities? Will you be using a city code?
export default {
name: 'temperature',
title: 'Temperature',
type: 'document',
fields: [
{
name: 'temperature',
title: 'Temperature',
type: 'number'
},
{
name: 'city',
title: 'City',
to: [
{type: 'city'}
]
type: 'reference'
}
]
}export default {
name: 'city',
title: 'City',
type: 'document',
fields: [
{
name: 'name',
title: 'name',
type: 'string'
},
]
}Yes, I imagined something like this, thanks. A new temperature reading would create a new document with a reference to the city, but I would have to update the previous document to show that the temperature was superceded
why? It's more recent, isn't it?
Doesn't the most recent temperature just take precedence?
No
I need to look back in time, to see what the temperature was say, in Ho Chi Minh City on 12 July 1996 for example
To use the internal fields _createdAt and _updatedAt, the query to find this temperature needs to check 12/Jul/96 >= _createdAt && 12/Jul/96 < _updatedAt
Well, in a database table/row model, each reading would be its own document, there would be no update.
Yes. But in a database model you could have two datetime fields, "effectiveFrom" and "effectiveTo". When the record is created the effectiveFrom is set to the current datetime. When a new value/record is created, the effectiveTo of the previous record is set.
Why do you need to duplicate this data, though?
I wouldnt want to duplicate the data though, sorry I didnt understand? If someone wants to see how average temperatures in various parts of the earth are increasing over time, I need to keep hostorical record of the temperature readings. The data for document "City" would not change (name, location, etc.) but the document "City Temperature History" refers to the City document, and would contain many records
ah, here's the issue: usually it's one document per "record", so you wouldn't even need to do this. You would just have one generic document and then a separate document for each reading for each time point. Otherwise, you'd have to create an array, temperatureReadings, within each document, but you need one for each city.
Oh, ok. So basically update the array when a new reading is recorded?
That would be an approach.
Excellent! I like it. I knew I would find an answer here. Im just used to thinking in database SQL terms
Many thanks user L
Right, ok, well it's a bit different, but the key is that if we use the one-record per measurement, you'll quick have 1000's of records, potentially millions, no? That would be heavy soon.
Not necessarily - depends on sampling frequency, so not record the temperature every hour but perhaps once a month, for say 300 cities?
Would this be a problem for Sanity?
so around 10200 documents in the first few years. As long as there isn't the potential to blow up too much, then one document per city per record (with built in timestamp) is all you need.
No, but the pricing increases at 10k documents.
Still, it's the best use of the money that we have in our stack.
Ok. I'll keep that in mind, and adjust sampling frequency accordingly
otherwise, you can just use a single document per city and it will only ever grow at a slower rate (only when new cities are added) and then have an array of temperatures and times.
the limits under the free plan seem very reasonable and i will try to keep under them. I was going with the single document per city + array option. Are there any technical limits with having an array of about 500-1000 small objects?
Not that I know of, but I haven't had that many objects in an array.
Ok. I'll guess I will find out. Thanks again for your help. I'm going to implement it now
Was this answer helpful?
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.
