-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
h.scheming_datastore_choices #132
Conversation
Thanks Ian, that is nice! I wonder whether it is in general a good strategy to use the datastore for CKAN-internal state that should also be applied to similar problems in new extensions. |
@hvwaldow I think the datastore is great for things like controlled lists. We can have however many columns we want, and it's fast and fairly easy for users to update. Those things aren't true for our tag vocabulary code. For static lists I've been using external JSON or CSV files and this new interface works with that sort of thing too. I should add helpers for those cases. |
@wardi OK, thanks. Another question: In case I fear that datastore could still become too slow (e.g. autocomplete for a very large list of terms) and I wanted to cache that in memory, would it be prudent to attach it to app_globals? Or better use Redis? |
I mentioned in #130 (comment) that this helper won't work for extremely large lists. If your list is too large to simply request the whole list any time you need an item then you'll need a way of asking for completions and translations from individual values->labels. That should work with datastore with the right index but you could do it in redis or by in-memory too. |
Adds the ability to use a datastore table as a choices list to #131