You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Franklin's database is currently organized around items as a single jsonb field with a special breakout of the collection for faster queries. This makes sense for users who only ever want to look things up by collection id, but for any kind of search, it's insufficient, or at least, the jsonb index has not behaved exactly as we expected in every circumstance (e.g. it wasn't used for collection lookups for a while). At the same time, there's a cost to indexing additional fields. It's impossible to know every use of Franklin up front, but there are two extremes we can think about:
users whose needs are 90+% met by fast spatial and time queries using only non-extension fields
users who want to search using fields from an extension with nested JSON, e.g., a user who wants fast searches over all the EO fields
Since the number of extensions is asymptotically ~infinity and we don't want to blow up the database with ~infinity indices, we should think about a way to expose configuration here to users who are deploying a Franklin service.
The text was updated successfully, but these errors were encountered:
Franklin's database is currently organized around items as a single jsonb field with a special breakout of the
collection
for faster queries. This makes sense for users who only ever want to look things up by collection id, but for any kind of search, it's insufficient, or at least, the jsonb index has not behaved exactly as we expected in every circumstance (e.g. it wasn't used for collection lookups for a while). At the same time, there's a cost to indexing additional fields. It's impossible to know every use of Franklin up front, but there are two extremes we can think about:Since the number of extensions is asymptotically ~infinity and we don't want to blow up the database with ~infinity indices, we should think about a way to expose configuration here to users who are deploying a Franklin service.
The text was updated successfully, but these errors were encountered: