-
Notifications
You must be signed in to change notification settings - Fork 10
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
Mount Oaisys inside Jupiter [ch109] #1361
Mount Oaisys inside Jupiter [ch109] #1361
Conversation
CI should pass once ualbertalib/oaisys#17 goes through and is referenced in this Gemfile |
app/models/thesis.rb
Outdated
@@ -9,6 +9,7 @@ class Thesis < JupiterCore::Doiable | |||
has_many_attached :files, dependent: false | |||
|
|||
scope :public_items, -> { where(visibility: JupiterCore::VISIBILITY_PUBLIC) } | |||
scope :belongs_to_set, ->(set) { where('member_of_paths::text LIKE ?', "%#{set}%") } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so we're consistent in our terminology (which is only going to get worse in phase 2 as the Community & Collection nesting gets joined by other nested relationships), let's use 'path' instead of set.
Also maybe throw a TODO on this so that once we've upgraded to Postgres 12 we come back and upgrade this query to use proper JSON operators instead of this terrible trick I came up with of casting the field to text.
app/models/item.rb
Outdated
# with an upgraded version of Postgresql this could be done more cleanly and performanetly | ||
scope :belongs_to_path, ->(path) { where('member_of_paths::text LIKE ?', "%#{path}%") } | ||
scope :record_created_from, ->(date) { where('record_created_at >= ?', date) } | ||
scope :record_created_until, ->(date) { where('record_created_at <= ?', date) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really tiny nit, but I think these names are slightly confusing? Or at least I feel like I have to stop and think about what from and until mean, and that I'd misinterpret the behaviour and maybe be surprised by the "up to and including" nature of the queries.
Maybe something like created_on_or_before(date)
and created_on_or_after(date)
? Just so it reads fluently and there's no confusion as to what something like Item.created_on_or_before(date)
returns when they start being used in non-OAI contexts (where there's going to be less awareness of what from
and until
mean in the OAI API context)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments on my second to last commit... from the other oaisys PR: Found some exceptions thrown regarding unpermitted parameters when running tests. When hitting /search with the header (Content-Type: application/json) or when running I also found tests failing regarding draft theses... I think these are appropriate fixes, we could still revert to checking the parameters manually if you think there could be too many complications, but I think they're all cleared up. |
Found an issue from doing |
a75d9be
to
e85b97a
Compare
# testing whether a value is in a json array, which newer version of Postgresql have. | ||
# | ||
# with an upgraded version of Postgresql this could be done more cleanly and performanetly | ||
scope :belongs_to_path, ->(path) { where('member_of_paths::text LIKE ?', "%#{path}%") } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor, just curious if we should worry about case sensitivity here? e.g use ILIKE
instead of LIKE
?
Maybe doesn't matter here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question...
You could make the argument that case-insensitivity would be cleaner/work if someone manually typed a URL with all-caps. This is all just a terrible hack to work around the fact that the version of Postgres in Prod is currently 9.2 and 9.2 doesn't really support proper JSON queries that would let us ask whether that string is in the member_of_paths
array. We're now building a new Production environment with Postgresql 12 that supports the proper query syntax, so this should just be switched to use the proper query instead.
I'll create a ticket/ quick PR to upgrade this query.
@@ -39,5 +39,8 @@ class Application < Rails::Application | |||
|
|||
config.redis_key_prefix = "jupiter.#{Rails.env}." | |||
|
|||
# Set an action on unpermitted parameters to raise an exception, used to validate parameters in Oaisys. | |||
config.action_controller.action_on_unpermitted_parameters = :raise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious the impact of this would be in production? Makes sense in Dev/Test over :log
but with production could be troublesome perhaps and could result in a lot of crashes that would be difficult to troubleshoot?
For example say someone links a page on ERA on a 3rd party site, let's say Slack. Slack may add additional params to the link, e.g era.ualberta.library.ca/search?q=thesis&utm_source=slack
for tracking. This would be an unpermitted param? Which means anyone clicking that link will get served a 500 error
Couldn't find much online to confirm this, except for this stackoverflow article:
https://stackoverflow.com/questions/57461284/action-on-unpermitted-parameters-on-production-environment
which highlights these same concerns.
Would you be able to verify this?
And if that is the case, maybe we just want to enable this in dev/test only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points, it has been decided that were going to set it to raise for dev/test and false in prod. Going to go back to manually checking oai parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got some small concerns on setting config.action_controller.action_on_unpermitted_parameters = :raise
in production. Can you double check this?
Some more context on the page parameter not being permitted in the place above. The page parameter is being permitted and used on line 64 of search_controller. Because it is permitted there doesn't mean it is permitted elsewhere as .permit returns a new ActionController::Parameters instance |
Note: this PR should probably be merged once the gemfile references an oaisys repo with all list identifiers commits (2 PRs are still open in oaisys) |
Now referencing final Oaisys list identifiers commit in the gemfile, ready to be merged (once approved). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added scopes, inflection, config for oaisys, and mounted the engine to the route.