Closed hrodmn closed 1 year ago
Approach sounds 👌
Let's add some tests to validate 🙏
Approach sounds 👌
The one thing I was wondering is if we should skip spatial/temporal columns altogether instead of passing those variables through to that function, but it seems like we need other attributes from the spatial columns besides bounds
so I did it this way.
Let's add some tests to validate 🙏
I added a few tests!
The one thing I was wondering is if we should skip spatial/temporal columns altogether instead of passing those variables through to that function, but it seems like we need other attributes from the spatial columns besides bounds so I did it this way.
I think it's fine to have them separate. Most people will have spatial index (hopefully) so them might want to avoid only the temporal calculation
Let's wait for @bitner 👍 👎
I do think that in order to actually be scalable, we do need to enable options to manage/store state beyond the scope of a single instance.
@bitner I think tipg
is almost in a good shape in order to support both case. I've started https://github.com/vincentsarago/tipg-aurora and https://github.com/vincentsarago/tipgstac to showcase how to use tipg with static
functions.
tipg
won't be able to support all the use case but I think right now we have a nice python package
which people can use or extent to fit their use case
As discussed in #139, Calculating the extent of spatial/datetime columns can be slow enough that serverless deployments of
tipg
are not possible.Skipping the extent calculations is one way to make application startup almost instantaneous! With this change, the user can set
TIPG_DB_SPATIAL_EXTENT=False
andTIPG_DB_DATETIME_EXTENT=False
to skip these calculations.I am not sure if passing these arguments all the way through to
pg_temp.tipg_properties
is the best way to accomplish this, but I got it working. If there is a cleaner way that you can think of please let me know!