Closed lboeman closed 4 years ago
Hmm, I guess the approach I was thinking about would be to have a function like what you've written, and call that function from within the store_forecast/obs/cdf procedures and abort if appropriate. Otherwise, we could just use read_site and check in python instead of adding a new procedure.
Now that I think about it again, I'm not sure if checking in sql or checking in python is best. Let's go with python for now. We might also want to check more than just tracking type (like capacity). Also need to make sure forecast and aggregate variables match if we don't already
Hmm, I guess the approach I was thinking about would be to have a function like what you've written, and call that function from within the store_forecast/obs/cdf procedures and abort if appropriate. Otherwise, we could just use read_site and check in python instead of adding a new procedure.
Now that I think about it again, I'm not sure if checking in sql or checking in python is best. Let's go with python for now. We might also want to check more than just tracking type (like capacity). Also need to make sure forecast and aggregate variables match if we don't already
That's a good point, this procedure is unnecessary. I had originally started working on something in line with what you intended, but I think that keeping the validation in python and the RBAC based control stuff in SQL is a good separation of concerns.
I'll remove the procedure, and check for matching aggregate variable if it doesn't exist.
I think the test failures are due to a recent pymysql update. Try restricting to 0.9.3 for datastore/test-requirements.txt and requirements.txt
closes #241 This adds a MYSQL procedure to check if a site has modeling parameters by checking for a non-null
tracking_type
column. The procedure is called from python before the subsequent call tostore_obs/fx/cdf
and raises a BadAPIRequestError with an appropriate message.@alorenzo175 what do you think of this approach?