I'd like to check a few queries generated by ActiveRecord, but I don't need to actually run them. Is there a way to get at the query before it returns its result?
Both of these articles should help you do what you want.
http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-do-it-s-thing
http://weblog.jamisbuck.org/2007/1/31/more-on-watching-activerecord
i think it's buried in:
construct_finder_sql,
http://groups.google.com/group/rubyonrails-talk/browse_frm/thread/38c492e3939dd9bf/?pli=1
tail -f log/development.log
Works in default settings or when you set your logger level to DEBUG.
Jamis' article is outdated, or at least doesn't work my Rails app (possibly due to some other reason with a 3 year old 30,000 line app). However this works in a console any time:
ActiveRecord::Base.connection.instance_variable_set :#logger, Logger.new(STDOUT)
Related
Is there a way to make the logged user (on superset) to make the queries on impala?
I tried to enable the "Impersonate the logged on user" option on Databases but with no success because all the queries run on impala with superset user.
I'm trying to achieve the same! This will not completely answer this question since it does not still work but I want to share my research in order to maybe help another soul that is trying to use this instrument outside very basic use cases.
I went deep in the code and I found out that impersonation is not implemented for Impala. So you cannot achieve this from the UI. I found out this PR https://github.com/apache/superset/pull/4699 that for whatever reason was never merged into the codebase and tried to copy&paste code in my Superset version (1.1.0) but it didn't work. Adding some logs I can see that the configuration with the impersonation is updated, but then the actual Impala query is with the user I used to start the process.
As you can imagine, I am a complete noob at this. However I found out that the impersonation thing happens when you create a cursor and there is a constructor parameter in which you can pass the impersonation configuration.
I managed to correctly (at least to my understanding) implement impersonation for the SQL lab part.
In the sql_lab.py class you have to add in the execute_sql_statements method the following lines
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
where cursor_kwargs is defined in db_engine_specs/impala.py as the following
#classmethod
def get_configuration_for_impersonation(cls, uri, impersonate_user, username):
logger.info(
'Passing Impala execution_options.cursor_configuration for impersonation')
return {'execution_options': {
'cursor_configuration': {'impala.doas.user': username}}}
#classmethod
def get_cursor_configuration_for_impersonation(cls, uri, impersonate_user,
username):
logger.debug('Passing Impala cursor configuration for impersonation')
return {'configuration': {'impala.doas.user': username}}
Finally, in models/core.py you have to add the following bit in the get_sqla_engine def
params = extra.get("engine_params", {}) # that was already there just for you to find out the line
self.cursor_kwargs = self.db_engine_spec.get_cursor_configuration_for_impersonation(
str(url), self.impersonate_user, effective_username) # this is the line I added
...
params.update(self.get_encrypted_extra()) # already there
#new stuff
configuration = {}
configuration.update(
self.db_engine_spec.get_configuration_for_impersonation(
str(url),
self.impersonate_user,
effective_username))
if configuration:
params.update(configuration)
As you can see I just shamelessy pasted the code from the PR. However this kind of works only for the SQL lab as I already said. For the dashboards there is an entirely different way of querying Impala that I did not still find out.
This means that queries for the dashboards are handled in a different way and there isn't something like this
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
My gut (and debugging) feeling is that you need to first understand the sqlalchemy part and extend a new ImpalaEngine class that uses a custom cursor with the impersonation conf. Or something like that, however it is not simple (if we want to call this simple) as the sql_lab part. So, the trick is to find out where the query is executed and create a cursor with the impersonation configuration. Easy, isnt'it ?
I hope that this could shed some light to you and the others that have this issue. Let me know if you did find out another way to solve this issue, or if this comment was useful.
Update: something really useful
A colleague of mine succesfully implemented impersonation with impala without touching any superset related, but instead working directly with the impyla lib. A PR was open with the code to change. You can apply the patch directly in the impyla src used by superset. You have to edit both dbapi.py and hiveserver2.py.
As a reminder: we are still testing this and we do not know if it works with different accounts using the same superset instance.
I need to set variables in root scope in one job to be used in a different job. The first job has a Javascript job entry, with the statements:
parent_job.setVariable("customers_full_path", "C:\\customers22.csv", "r");
true;
But the compilation fails with:
Couldn't compile javascript:
org.mozilla.javascript.EvaluatorException: Can't find method
org.pentaho.di.job.Job.setVariable(string,string,string). (#2)
How to set a variable at root level in a Javascript job entry?
Sorry for the passive agressive but:
I don't know if you are new to Pentaho but, the most common mistake for new users, with previous knowledge of programming, is to be sort of 'addicted' to know methods, as such you are using JavaScript for a functionality that is built in the tool. Both Transformations(KTR) and JOBs(KJB) have a similar step, you can better manipulate this in a KTR.
JavaScript steps slow down the flow considerably, so try to stay away from those as much as possible.
EDIT:
Reading This article, seems the only thing you're doing wrong is the actual syntax of the command..
Correct usage :
parent_job.setVariable("Desired Value", [name_of_variable]);
The command you described has 3 parameters, when it should be 2. If you have more than 1 variable you need to set, use 3 times the command. Try it out see if it works.
I have an UPDATE pass through query saved in Access 2007. When I double-click on the pass through query it runs successfully. How can I get this query to run from VBA? I'd like it to run when my "splash screen" loads.
I'm currently using the following code:
CurrentDb.Execute "Q_UPDATE_PASSTHROUGH", dbSQLPassThrough
But I get the following message:
The pass-through query contains all the connection information and I've confirmed the SQL syntax is correct by running it multiple times, so not sure what I'm missing in my VBA call.
Use the QueryDef's Execute method:
CurrentDb.QueryDefs("Q_UPDATE_PASSTHROUGH").Execute
I don't think you should need to explicitly include the dbSQLPassThrough option here, but you can try like this if you want it:
CurrentDb.QueryDefs("Q_UPDATE_PASSTHROUGH").Execute dbSQLPassThrough
I recently ran into the same problem. While the above mentioned Execute method is working for most cases, some people (me included) experiencing a Run-time error '3001': Invalid Argument when using the parameter dbSQLPassThrough. This was also addressed in the answer above me and happens even in the simplest SQL-statements.
For those who are having the same problem, I recommend using the OpenQuery method as alternative.
A valid substitution for the following code
CurrentDb.QueryDefs("Q_UPDATE_PASSTHROUGH").Execute
would be
DoCmd.OpenQuery "Q_UPDATE_PASSTHROUGH"
I know this thread is 4 years old, however, searching for a solution for the not working Execute method on Google brings you directly to this thread which is why I thought it would be useful to add an alternative solution which solved this problem for me.
I confirm that the QueryDef's Execute method is the recommended way to achieve your goal.
CurrentDb.QueryDefs("Q_UPDATE_PASSTHROUGH").Execute
However, I can point out that in a similar case with Access 2010, using dbSQLPassThrough for the Options parameter caused a Run-time error '3001': Invalid Argument.
I access to my webservice like that:
http://localhost/SuiPService/SuiPDataService.svc/GetShowCodeFiltered?&showName='auto'
It works fine, but when I try:
http://localhost/SuiPService/SuiPDataService.svc/GetShowCodeFiltered?&showName='auto''
it failed, ok this I understand, but if I encode the url like that:
http://localhost/SuiPService/SuiPDataService.svc/GetShowCodeFiltered?&showName='auto%27'
I get the error Bad Request - Error in query syntax. too
What is the solution?
The reason it's failing is because %27 is equal to '.
Everything is encoded before being sent to the web server, even if the URL box doesn't say so.
This will become hard to maintain and possibly confuse your users. I'd change it so you aren't padding the variable with ' and that way you can use http://localhost/SuiPService/SuiPDataService.svc/GetShowCodeFiltered?&showName=auto' if you need to have a ' after it.
Also, if you need the '' around auto. Consider doing this on the server side.
It looks like your using this to build an SQL query...
See here for the reason PHP deprecated it for that exact reason: http://en.wikipedia.org/wiki/Magic_quotes
Hope this helps,
Jeffrey Kevin Pry
How to change the environment variable of rails in testing
You could do
Rails.stub(env: ActiveSupport::StringInquirer.new("production"))
Then Rails.env, Rails.development? etc will work as expected.
With RSpec 3 or later you may want to use the new "zero monkeypatching" syntax (as mentioned by #AnkitG in another answer) to avoid deprecation warnings:
allow(Rails).to receive(:env).and_return(ActiveSupport::StringInquirer.new("production"))
I usually define a stub_env method in a spec helper so I don't have to put all that stuff inline in my tests.
An option to consider (as suggested in a comment here) is to instead rely on some more targeted configuration that you can set in your environment files and change in tests.
Rspec 3 onwards you can do
it "should do something specific for production" do
allow(Rails).to receive(:env).and_return(ActiveSupport::StringInquirer.new("production"))
#other assertions
end
Sometimes returning a different environment variable can be a headache (required production environment variables, warning messages, etc).
Depending on your case, as an alternate you may be able to simply return the value you need for your test to think it's in another environment. Such as if you wanted Rails to believe it is in production for code that checks Rails.env.production? you could do something like this:
it "does something specific when in production" do
allow(Rails.env).to receive(:production?).and_return(true)
##other assertions
end
You could do the same for other environments, such as :development?, :staging?, etc. If you don't need the full capacity of returning a full environment, this could be another option.
As a simpler variation on several answers above, this is working for me:
allow(Rails).to receive(:env).and_return('production')
Or, for as I'm doing in shared_examples, pass that in a variable:
allow(Rails).to receive(:env).and_return(target_env)
I suspect this falls short of the ...StringInquirer... solution as your app uses additional methods to inspect the environment (e.g. env.production?, but if you code just asks for Rails.env, this is a lot more readable. YMMV.
If you're using something like rspec, you can stub Rails.env to return a different value for the specific test example you're running:
it "should log something in production" do
Rails.stub(:env).and_return('production')
Rails.logger.should_receive(:warning).with("message")
run_your_code
end