I have an extensive program that is running on my server. The line with the error looks like the following:
result[0].update(dictionary)
result[0] looks like ("label",{key:value,...}) so I got an error saying that a tuple does not have update
when I fixed it to be result[0][1].update(dictionary), I got the same error!
I then added print "test" above to see what happened, and I got the same error, but it gave me the error occurring at the print statement. This tells me that the code the server is running is the original and not the edited one. I tried restarting the server. I have saved my code. I do not understand why nor how this is happening. What could be causing this and how can I make it so that the server recognizes the newer version?
error message
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/background_task/tasks.py", line 160, in run_task
tasks.run_task(task.task_name, args, kwargs) [2/1832]
File "/usr/local/lib/python2.7/dist-packages/background_task/tasks.py", line 45, in run_task
task.task_function(*args, **kwargs)
File "/.../proj/tasks.py", line 10, in automap_predict
automap_obj.predict()
File "/.../proj/models.py", line 317, in predict
prediction = predictions[1]
File "/.../proj/models.py", line 143, in predict
#this is a recursive call
File "/.../proj/models.py", line 143, in predict
#this is a recursive call
File "/.../proj/models.py", line 127, in predict
#result[0].update(dictionary) this happens at the base case of the recursion
AttributeError: 'tuple' object has no attribute 'update'
notice that I am getting this error on a line that is commented out. Displaying that this is not the code that is really running.
view
def view(request,param):
run_background_task(param)
return redirect("project.view.reload")
background_task
#background(schedule=0)
def run_background_task(param):
obj = MyModel.objects.get(field=param)
obj.predict()
predict function
This is where the result gets created. I am not permitted to show this code, but note that I am sure that the actual code is irrelevant. It was working. I changed it to make a quick update. I got an error. I then fixed the error, but proceeded to get the same error. I even went back to the old version that was working and I still get the same error. Therefor this error has nothing to do with the contents of this function.
Let me know if I can be of any more help.
If you are running a development server provided with django, namely ./manage.py runserver you should not experience this problem, since it automatically recompiles upon .py file saving. But if you are running wsgi say with apache server it is a common issue, but with a very simple solution. Basically what happens, whenever you change a .py file, server will still use a previously compiled python file. So solution is either restart apache sudo service apache2 restart (which is an overkill) or simply run touch wsgi.py, wherever your wsgi.py is located within a project, which will tell it to recompile .py files. Of course you can also delete the .pyc files, but that is too tedious.
Edit:
I just notice that you are using #background decorator, which make me believe you are using django-background-task. If that's the case, you will have to make sure this app actually takes your code changes into account too, which may not happen automatically while recompiling python files using touch wsgi.py approach. I don't have experience with this particular app, but for example with celery, which is a lot more sophisticated app for scheduling tasks, you would also have to restart the worker in order to reflect the changes in code, since worker actually stores a pickled version of the code.
Now after checking out the django-background-task app (which seems like the one you are using), in theory you should't have to do anything special, but just to make sure you can clear out any scheduled tasks and reschedule them again. I haven't tried but you should be able to do it through ./manage.py shell:
>>> from background_task.tasks import tasks
>>> tasks._tasks = {}
And probably you'll even have to clear out the db, for the DBTaskRunner:
>>> from background_task.models import Task
>>> Task.objects.all().delete()
May be this is what you are looking for?
result = (
("item1",{'key1': 'val1'}),
("item2",{'key2': 'val2'}),
)
my_dict = {
'key1': 'updated val',
'new key': 'new value'
}
pprint.pprint(result[0]) # Result: ('item1', {'key1': 'val1'})
key, dct = result[0]
dct.update(my_dict)
pprint.pprint(result) # Result: (('item1', {'key1': 'updated val', 'new key': 'new value'}), ('item2', {'key2': 'val2'}))
The issue may be related to compiled python files or ".pyc" files located in your project folder on your server. These files are automatically generated as the python code is interpreted. Sometimes these files aren't re-compiled even if new code is present and it keeps running the old code.
You can install "django-extensions" via pip and it comes with a handy manage.py command that can help you clear those files:
python manage.py clean_pyc
If that doesn't work then you need to restart your wsgi server that's running the code since the python code is in memory.
If the code is not updating, solution will depend on how you are serving your application. If you are using ./manage.py runserver, you should not be having problems. Also if serving with apache + mod_python if you restart the sever the code should be reloaded.
But I assume you are not doing either of them, since you still have this problem. If your using uWSGI or gunicorn, they runs in a separate processes from the server, you would need to restart them separately. uWSGI can be set up also to reload the app every time its setting file changes, so normally I just call touch myapp.ini to reload the code.
Basically what happens, whenever you change a .py file, server will still use a previously compiled python file. So solution is either restart apache sudo service apache2 restart (which is an overkill) or simply run touch wsgi.py, wherever your wsgi.py is located within a project, which will tell it to recompile .py files. Of course you can also delete the .pyc files, but that is too tedious.
You are using #background decorator, which make me believe you are using django-background-task. If that's the case, you will have to make sure this app actually takes your code changes into account too, which may not happen automatically while recompiling python files using touch wsgi.py approach. I don't have experience with this particular app, but for example with celery, which is a lot more sophisticated app for scheduling tasks, you would also have to restart the worker in order to reflect the changes in code, since worker actually stores a pickled version of the code.
Now after checking out the django-background-task app (which seems like the one you are using), in theory you should't have to do anything special, but just to make sure you can clear out any scheduled tasks and reschedule them again.
I had a similar problem and it was gunicorn cache wasn't updating.
First try
sudo systemctl restart gunicorn
if that doesn't solve it:
sudo systemctl start gunicorn
sudo systemctl enable gunicorn
sudo systemctl status gunicorn (Check for faults)
sudo systemctl daemon-reload
sudo systemctl restart gunicorn
That then should update the server
It seems your result is not as you think it is, I just used the same format as you described and you see it works. You should check the function that it is returning proper data or not.
>>> a = (('label', {'k':'3'}),)
>>> print (a[0])
('label', {'k': '3'})
>>> a[0][1].update({'k':'6'})
>>> print (a[0])
('label', {'k': '6'})
>>>
FYI, As you see Here, Tuples are immutable sequence types and therefore they do not support updating and that is why they do not need an update function to be defined.
If you want to update the result[0] which itself is a tuple, (as clearly understood by the error message shown ), you have to create a new tuple with the entities that are updated.
I have a coverage report that may be lying or distorted. It says that I have coverage for a line in my Django model code. I can't see where that line is being exercised. I can see that the module is imported, that the class is imported, but not that it's being invoked/instantiated.
Thus, coverage report says I have Line A covered. Presumably that means Line B, somewhere, is exercising it. I'd like to know where Line B is. Is there a way to find the set of Line-B's (one or more) that are calling Line A, in my tests?
It seems this could be an annotation in the coverage report somehow/somewhere. It's definitely knowable, since coverage has to keep track of a thing being used.
I'm not seeing it.
If this isn't implemented, I'd like to suggest it. I know, it may be too complex as a full stack trace for each line of execution. But, maybe just the inspect of the immediate calling frame would be a good start, and helpful.
New in coverage.py 5.0 are dynamic contexts which can tell you what test ran each line of code. It won't tell you the immediate caller of the line, but it's a start.
Here's a fun way to discover what covers that line:
Insert a bug in the line.
If you then run the tests, the ones truly covering the line will fail. The stacktraces should include Line B.
I'm not sure how to approach this, whether it's a Django, Python, or even Terminal solution that I can tweak.
The thing is I'm learning Django following a book (reference here, really like it), and whenever I run the tests, I get really long output in the terminal for debugging matters. Obviously there's many traceback functions that get called after another, but what started bugging me is that the file paths are very long and they all have the same project folder... which is long by itself, and then it adds all the virtualenv stuff like this:
Traceback (most recent call last):
File "home/user/code/projects/type_of_projects_like_hobby/my_project_application/this_django_version/virtualenv/lib/python3.6/site-packages/django/db/models/base.py", line 808, in save
force_update=force_update, update_fields=update_fields)
Since the paths take two or more lines, I can't focus on what functions I should be looking at clearly.
I have looked at the verbosity option when calling manage.py test but it doesn't help with the paths. If anyone has an idea on how to ~fix~ go about this issue, it'd be cool.
Thanks guys.
There's really not a way to change the behavior (this is how Python displays tracebacks). But you can pipe the output into something that will reformat it. For example, here's a tool you can pipe traceback output into that will do various types of formatting.
Background:
I'm running my Python program under PyCharm on Windows 10 with three different run configurations.
All seem to run through the bulk of the program fine, doing the logic work without errors.
At the end of the program, there is an attempt to open a file handle, which works on two of the run configurations, but not one, despite the different configurations not affecting the parameters of this call.
Details:
This is the piece of code that it is errors in one of the configurations.
f = open(global_args[2], "w")
# global_args[2] is always 'new_output.xml'. I've thoroughly checked this
The error is below.
Traceback (most recent call last):
File "C:/Projects/obfuscated/trunk/PythonXMLGenerator/generate_xml.py", line 270, in <module>
instance.main()
File "C:/Projects/obfuscated/trunk/PythonXMLGenerator/generate_xml.py", line 235, in main
f = open(global_args[2], "w")
PermissionError: [Errno 13] Permission denied: 'new_output.xml'
Just for extra information, although I have a feeling it's not relevant, here are two of the run configurations.
//Not working
1.0 new_output.xml localdb (LocalDB)\MSSQLLocalDB (2) x x x "0:Upload,1:Modify,2:Delete,3:Download,4:ApplyTemplate,5:RemoveTemplate"
//Working
1.0 new_output.xml mysql localhost (2) obfuscated obfuscated obfuscated "0:Upload,1:Modify,2:Delete,3:Download,4:ApplyTemplate,5:RemoveTemplate"
It's maybe worth nothing that I am closing the file handle with f.close() after trying to open it.
Recap:
Although the error is happening on a line which shouldn't rely on the context of the wider program, the context nonetheless seems to have an effect and I can't figure out why.
I believe there shouldn't be any issues with write permission in general, as it does work for 2 of the 3 configurations.
Anyone have any thoughts?
P.S. If any more details are needed, I can provide them. Given the confusing nature of this problem, I'm not sure exactly what is necessary.
Not a code problem as it turns out.
For this particular broken run configuration, PyCharm was not setting a working directory.
I have an existing system where an oracle database is populated with metadata by a series of Python files. There are around 500, and the current method of running them one at a time is taking around an hour to complete.
To cut down on this runtime, I've tried threading the individual files, running them in concurrently, but I've been getting a the error
pyodbc.IntegrityError: ('23000', '[23000] [Oracle][ODBC][Ora]ORA-00001: unique constraint (DB.PK_TABLE_NAME) violated\n (1) (SQLExecDirectW)')
with a traceback to the following call:
File "C:\file.py", line 295, in ExecuteSql
cursor.execute(Sql)
Can anyone shed any light on this for me by any chance? This doesn't seem to be happening if a file which has thrown the error is then run individually, which leads me to suspect this is an access issue where two files are trying to write to the DB at once. I hope this is not the case, as that will likely veto this approach entirely.
I eventually realised that the issue was coming from the way that the SQL submitted to the database was being constructed.
The ID for the table was being generated by a "GetNext()" function, which got the current max ID from the table and incremented it by one. This was failing when multiple files were being run - and trying to use the same ID based on this generated - at the same time.