I am using django debug-toolbar on django 1.4. The problem is, it gives me incorrect summary results.
For example, on a landing page which produces one query (check to see if the user is logged in). DT says that there are 43 queries taking 17.27ms. However, when I actually click the SQL queries tab, it does show the correct result -- 1 query in 0.47ms.
Is DT incompatible with 1.4 or something, or is there a way to fix this?
It looks like this was a known issue according to github. I recently had exactly the same problem.
https://github.com/django-debug-toolbar/django-debug-toolbar/issues/88
I managed to resolve the issue by simply updating the django-toolbar to the latest version.
Related
Django time zone support is wrong (but, I'm sure there is some thing I miss)
I SET time to America/Los_Angeles with SERVER(UBUNTU), mysql, and django too.
And the server is Oregon and I am in CA. As I know, there is no time difference.
I printed all of time with php, mysql, and django too.
all results are PST!
However, I get date from server. It's totally different. (-7 hours from the DB's date)
If turned off TZ support in settings.py, the django print exactly same date and time form DB
I searched 3 hours with no luck :(
what should I check more or change?
Thanks in advance :)
========================================================
;UPDATE
Django assumed DB as UDT time. then force calculate to location time as -7 PDT
(HAVE TO) Insert through Django with timezone.now() Then Solved !! :)
You don't mention if you've called "activate" on your timezone yet, I suspect that might be the problem. The 7 hour from PDT offset would be GMT.
At the very least, call timezone.activate(sometz) as detailed here https://docs.djangoproject.com/en/1.5/topics/i18n/timezones/#selecting-the-current-time-zone -
Making a couple test views to toggle between tzs should be enough to see if that's causing your issue. This activates it for the thread, so depending on your users use patterns for your site, you may want to call activate through middleware as described in that doc page.
we are experiencing some very odd errors in our installation.
Some times out of nowhere Sitecore throws an error:
Assert: Value Cannot be null. Parameter: Item.
The closest i have come to identifying the problem is narrowing it down to either an index or the web database.
Anyway, if I log into sitecore the Item is just missing, i can fix it in 3 ways:
Rebuild the index.
Recycle app pool
iisreset
Does any of you have an idea why this might be happening? We are running Sitecore.NET 6.5.0 (rev. 120706). Any help will be deeply appreciated.
You are describing a system stability issue, so I recommend opening a ticket with Sitecore support (http://support.sitecore.net). This sort of issue is difficult to troubleshoot over Stack Overflow, since we do not have access to your logs and configuration.
When opening the ticket, I recommend using the Support Package Generator which bundles up all the information (Web.config, App_Config files, IIS settings, Sitecore log files) that Sitecore Support needs to troubleshoot the issue. It's a pretty nifty tool.
That said, from what you describe, it sounds like the issue is related to caching. The fact that restarting IIS resolves the issue indicates that the item is in the Web database, but the runtime doesn't see it. You can prove out whether this is the issue by clearing cache using the /sitecore/admin/cache.aspx screen. If your cache is not getting updated properly, you should review your configuration against the guidelines in the SDN Scaling Guide.
Based on knowing you're using the Advanced Database Crawler, your issue may be how you're converting a SkinnyItem to an Item. I've had this issue before. If you look at the SkinnyItem.cs class, there's a GetItem() method to convert it into an Item. You can see it uses the database to get the item by its ID, language, and version number. Its possible that when you publish from master to web, you are publishing a new version # of an existing item and thus the new version exists in the web DB, but the index is not updated and references the old version. So, this GetItem() call would use the previous version # and the item would be null. One way to fix this is instead of calling that GetItem() method, just use your own code to get the latest version of that item from Sitecore, e.g.
Item item = Sitecore.Context.Database.GetItem(someSkinnyItem.ItemID);
Instead of
Item item = someSkinnyItem.GetItem();
Here's an example flow:
Foo item created in master DB as version 1.
Publish Foo to web
Index will pick up version 1 in web DB and put in index.
Any querying code against index will convert the SkinnyItem to an Item via that GetItem() method and will pass 1 as the version #.
Page will load, no error in log
Back in master, create version 2 of Foo and publish.
Index may not get updated right away or even if configured wrong.
Code that looks against index will call GetItem() and still call with version 1 since that's in the index
But when you published, web no longer has version 1, it now has version 2, and thus that specific version of that item Foo is null
Error shows in log
On a similar note, here's a blog post by Alex Shyba (creator of the ADC) on how to sync HTML cache clearing with the index updates. That may help.
I have a "DatabaseError: current transaction is aborted" that comes and goes (to be specific, 11 times out of 841) in a Django 1.3 project using Postgres. The project is a quiz site and the error occurs when a user submits the answer form in the view. From the database's perspective, the process involves a number of queries and looks like this:
Gather all of the correct answers for the question (they are multiple choice and may need more than one answer)*
Grab the user's profile
Save this answer
Query for the user's new point total
Save the total to their profile
Check to see if they qualify for a new reward
Award new reward if they do
Somewhere in that tortured process, this error crops up (I'm guessing because one query isn't waiting for the others). Is there a way for me, in production (i.e., DEBUG = False), to log the database errors just in this case? I'm on WebFaction and the Postgres error logs are not available to me. Could I steal something from this middleware example to fire in just this specific case?
Alternatively, is there a better way to find this error or should I be wrapping the individual queries in transactions (unfortunately they aren't all in the same place in the code, not sure if wrapping the view in a transaction decorator would help)?
*Just to confuse matters, the multiple right answers requirement was added in the middle of development and then dropped right before we went live, so I could simplify this process somewhat, basically skipping steps 1 and 4, but I'd like to know a general answer to this sort of mysterious issue.
You haven't said where in your 7 steps you have transactions that begin and end. That would be helpful to know.
One source of "transaction aborted" messages is due to deadlocks. More details would be in the PostgreSQL logs.
But the bottom line is that you will continue to have a painful and time-consuming experience debugging PostgreSQL if you can't get access to your PostgreSQL error messages. Take that up with WebFaction. If they can't helpful and your time is worth much, your bottom line costs will be lower by moving to an environment that provides this fundamental feature.
You have to enable autocommit for the transaction. In your DATABASES entry, include:
'OPTIONS': {'autocommit': True,},
By default, Django opens a transaction at the first query. By using this option, you manually have to start a transaction (e.g. using #commit_on_success). Since there is no transaction open anymore, you'll get the actual error that was previously masked by the transaction error.
The autocommit setting will be the new default for Django 1.6, see https://docs.djangoproject.com/en/dev/ref/databases/#postgresql-notes
If I got to calendar, click on To Do, then try to add an event, the form pops up, I fill it out, press save, but no Event gets added.
In the SQL error log's I see an error like this:
2011-09-29 14:57:07 EDT ERROR: null value in column "visibility" violates not-null constraint
2011-09-29 14:57:07 EDT STATEMENT: insert into
vtiger_activity(activityid,subject,date_start,time_start,time_end,due_date,status,eventstatus,priority,sendnotification,activitytype,visibility,duration_hours,duration_minutes,location,recurringtype,notime)
values('235','Testing','2011-09-29','19:50',NULL,'2011-09-29','Not Started',NULL,'High','0','Task',NULL,NULL,NULL,NULL,NULL,'0')
So, for some reason, it is trying to add a To-Do while inserting null values. My biggest problem is that I cannot locate the origin of the query. So, basically, the most important thing I am asking is what file takes the data that was input into the todosave form and turns it into a query.
I don't know if many people on here use Vtiger, but I couldn't figure this out so I went ahead and posted anyway. The official documentation is not very helpful in my opinion.
Thanks for everything, have a good day.
This might be an isolated case, but was any of the modules modified recently? In this case, I would assume that it would be the Calendar module. I've tested this on the demo website and on my vTiger installation and it works fine..
Perhaps you can download a fresh copy of vTiger and replace the modules/Calendar all its content.
By the way, another place to ask if you have any questions, is the vTiger forums.
http://forums.vtiger.com/index.php
Usually you can ask it in the Help - 5.2.1 section. Hope this helps!
I am using the API V2 "salesOrderList" for receiving a list of all the Orders which have been placed in Magento. But the SOAP Response is showing me an error as:-
Item (Mage_Sales_Model_Order) with the same id "1" already exist
I am using the Magento Enterprise version 1.9.0.0.
After looking into the SQL & searching the database, I found that for each Order, the SQL is providing 4 records for the same Order Entity ID; with the difference being only in the name fields of the billing & shipping area. Also the query is doing two Left Joins with the same database table "sales_flat_order_address" by using two different aliases (one for billing & another for shipping). From my understanding, this should have worked, which is not happening.
Can anyone please suggest as to what is happening & what can be done to recover from this error?
Any help is appreciated and thanks in advance.
Roughly, Magento is creating an order collection for you and attempting to load all the records. This collection has a rule that only allows it to create one order object for each ID, so when your additional object is loaded an exception is thrown.
The left joins could be the issue, but it's hard to say off the bat. Could you post a little detail on how you are making the API call? An incorrect join can often have this problem.
EDIT:
If you're using the default code, my first guess would be that there are erroneous records in the database, or that this is an upgraded Magento system which had a bad upgrade in the past. Try this on a clean copy of your EE version pointing to the same database. If the same problem occurs, you may need to spelunk in the database looking for the reason for the problematic data load. Since you already have the query, you may want to separate out parts of the query to see if some subquery is returning too much data.