Opened 14 years ago
Closed 14 years ago
#9504 closed defect (fixed)
It's back: TypeError: expecting datetime, int, long, float, or None; got <class 'genshi.template.eval.Undefined'>
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.12.1 |
| Component: | version control/log view | Version: | |
| Severity: | major | Keywords: | resync |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description (last modified by )
This is similar to ticket #5932, but doing a resync did not fix the problem, and there are no revisions missing.
I am using the following link provided by the TracHacks:TracTicketChangesetsPlugin plugin: https://<host>/trac/testproject/log/pOFDFT/?rev=35
where 'testproject' is the Trac project name, and pOFDFT is an svn repository name, defined in the Admin|Version Control|Repositories panel. (Note that pOFDFT actually represents a project within a repository.)
When I click on the above link, I get:
TypeError: expecting datetime, int, long, float, or None; got <class 'genshi.template.eval.Undefined'>
File "/usr/local/raas/python-2.5.2/lib/python2.5/site-packages/Trac-0.12-py2.5.egg/trac/versioncontrol/templates/revisionlog.html", line 153, in <Expression u'dateinfo(change.date)'>
Code fragment:
Line
148 <a py:otherwise="" class="chgset" href="${href.changeset(item.rev, reponame, item.path)}"
149 title="${_('View changeset [%(rev)s] restricted to %(path)s',
150 rev=display_rev(item.rev), path=item.path or '/')}"> </a>
151 </py:choose>
152 </td>
153 <td class="age" py:content="dateinfo(change.date)" />
154 <!--
155 <td class="age" py:content="change.date" />
156 -->
157 <td class="author" py:content="authorinfo_short(change.author)" />
158 <td class="summary" py:choose="">
Local variables:
Name Value
__data__ [{'is_separator': False, 'odd_even': 'even', 'chgset_context': <Context ...
File "build/bdist.linux-i686/egg/trac/timeline/web_ui.py", line 263, in dateinfo
Local variables:
Name Value
date <Undefined 'date'>
req <Request "GET '/log/pOFDFT/'">
self <trac.timeline.web_ui.TimelineModule object at 0xb605436c>
File "build/bdist.linux-i686/egg/trac/util/datefmt.py", line 103, in pretty_timedelta
Local variables:
Name Value
resolution None
time1 <Undefined 'date'>
time2 None
File "build/bdist.linux-i686/egg/trac/util/datefmt.py", line 64, in to_datetime
Local variables:
Name Value
t <Undefined 'date'>
tzinfo None
File "/usr/local/raas/python-2.5.2/lib/python2.5/site-packages/Trac-0.12-py2.5.egg/trac/versioncontrol/templates/revisionlog.html", line 153, in <Expression u'dateinfo(change.date)'>
<td class="age" py:content="dateinfo(change.date)" />
File "build/bdist.linux-i686/egg/trac/timeline/web_ui.py", line 263, in dateinfoFile
"build/bdist.linux-i686/egg/trac/util/datefmt.py", line 103, in pretty_timedeltaFile
"build/bdist.linux-i686/egg/trac/util/datefmt.py", line 64, in to_datetime
The only thing that worked was to follow cboos' suggestion in ticket 5932 to replace "dateinfo(change.date)" with "change.date" alone.
Once I did that, I got a display of all the revisions starting with the revision specified in the URL all the way back to revision 1.
System Information: User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Trac 0.12 CustomFieldAdmin 0.2.3 Genshi 0.6 mod_python 3.3.1 MySQL server: "4.1.22", client: "4.1.22", thread-safe: 0 MySQLdb 1.2.2 Python 2.5.2 (r252:60911, Sep 10 2008, 18:05:27) [GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] setuptools 0.7a1 Subversion 1.5.2 (r32768) jQuery 1.4.2 Enabled Plugins: CustomSelectAdmin.customselectadmin N/A /usr/local/raas/python-2.5.2/lib/python2.5/site-packages/CustomSelectAdmin-0.5-py2.5.egg/CustomSelectAdmin/customselectadmin.pyc IniAdmin 0.2 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/IniAdmin-0.2-py2.5.egg TracAccountManager 0.2.1dev-r7737 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracAccountManager-0.2.1dev_r7737-py2.5.egg TracCustomFieldAdmin 0.2.3 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracCustomFieldAdmin-0.2.3-py2.5.egg TracNoAnonymous 2.0 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracNoAnonymous-2.0-py2.5.egg TracTags 0.6 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracTags-0.6-py2.5.egg TracTicketChangesets 1.0dev /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracTicketChangesets-1.0dev-py2.5.egg TracWysiwyg 0.12.0.2-r8148 /var/local/raas/python-2.5.2/lib/python2.5/site-packages/TracWysiwyg-0.12.0.2_r8148-py2.5.egg
The output from svn log --xml -v -r35 is:
<?xml version="1.0" encoding="utf-8"?> <log> <logentry revision="35"> <author>dmcr</author> <date>2010-07-14T18:35:10.000755Z</date> <paths> <path action="M">/pOFDFT/trunk/OFDFT.f90</path> </paths> <msg>1st test to try to fix ticket 275. Made a change to the log message. </msg> </logentry> </log>
Don't know if this is the correct fix, but it's the only thing that I tried that got it to work.
Any further debugging you want me to do?
Dennis
Attachments (0)
Change History (5)
comment:1 by , 14 years ago
| Description: | modified (diff) |
|---|---|
| Keywords: | resync weird added |
| Milestone: | → next-major-0.1X |
| Severity: | normal → major |
comment:3 by , 14 years ago
I think you meant to refer to 5932#comment:25. If by a "full resync" you mean "trac-admin /path/to/env repository resync", then I have done that a couple of times. Here are the contents of both my node_change and revision tables, and you can see that there are no revisions missing from the revision table:
mysql> select rev,path,node_type,change_type,base_path,base_rev from node_change order by rev; +------------+-------------------------+-----------+-------------+-------------------------+----------+ | rev | path | node_type | change_type | base_path | base_rev | +------------+-------------------------+-----------+-------------+-------------------------+----------+ | 0000000002 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 1 | | 0000000003 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 2 | | 0000000004 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 3 | | 0000000005 | trunk/Output.f90 | F | E | trunk/Output.f90 | 1 | | 0000000005 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 4 | | 0000000006 | trunk/Output.f90 | F | E | trunk/Output.f90 | 5 | | 0000000007 | trunk/RhoOptimizers.f90 | F | E | trunk/RhoOptimizers.f90 | 1 | | 0000000008 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 5 | | 0000000009 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 8 | | 0000000010 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 9 | | 0000000011 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 10 | | 0000000012 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 11 | | 0000000013 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 12 | | 0000000014 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 13 | | 0000000015 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 14 | | 0000000016 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 15 | | 0000000017 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 16 | | 0000000018 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 17 | | 0000000019 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 18 | | 0000000020 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 19 | | 0000000021 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 20 | | 0000000022 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 21 | | 0000000023 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 22 | | 0000000024 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 23 | | 0000000025 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 24 | | 0000000026 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 25 | | 0000000027 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 26 | | 0000000028 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 27 | | 0000000029 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 28 | | 0000000030 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 29 | | 0000000031 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 30 | | 0000000032 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 31 | | 0000000033 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 32 | | 0000000034 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 33 | | 0000000035 | trunk/OFDFT.f90 | F | E | trunk/OFDFT.f90 | 34 | +------------+-------------------------+-----------+-------------+-------------------------+----------+ 35 rows in set (0.00 sec) mysql> select rev,time,author from revision order by rev; +------------+------------------+--------+ | rev | time | author | +------------+------------------+--------+ | 0000000002 | 1180035687701001 | | | 0000000003 | 1180121811643378 | dmcr | | 0000000004 | 1180122302252883 | dmcr | | 0000000005 | 1180127829972022 | dmcr | | 0000000006 | 1180471598799079 | dmcr | | 0000000007 | 1180472653662737 | dmcr | | 0000000008 | 1181142617414719 | dmcr | | 0000000009 | 1229033611689838 | dmcr | | 0000000010 | 1229034359232123 | dmcr | | 0000000011 | 1229035284320930 | dmcr | | 0000000012 | 1229036545121075 | dmcr | | 0000000013 | 1229036572274973 | dmcr | | 0000000014 | 1229036588388866 | dmcr | | 0000000015 | 1229036604639276 | dmcr | | 0000000016 | 1229036623354549 | dmcr | | 0000000017 | 1229544479282060 | dmcr | | 0000000018 | 1278969208243283 | dmcr | | 0000000019 | 1278969556314448 | dmcr | | 0000000020 | 1278971237243046 | dmcr | | 0000000021 | 1278972466792882 | dmcr | | 0000000022 | 1278974557885126 | dmcr | | 0000000023 | 1278975076098647 | dmcr | | 0000000024 | 1278975215203241 | dmcr | | 0000000025 | 1278980440111141 | dmcr | | 0000000026 | 1278981807600045 | dmcr | | 0000000027 | 1279029377271543 | dmcr | | 0000000028 | 1279029441895253 | dmcr | | 0000000029 | 1279029618306565 | dmcr | | 0000000030 | 1279029746468488 | dmcr | | 0000000031 | 1279029831918038 | dmcr | | 0000000032 | 1279055687064404 | dmcr | | 0000000033 | 1279055820273561 | dmcr | | 0000000034 | 1279059471786980 | dmcr | | 0000000035 | 1279132510000755 | dmcr | +------------+------------------+--------+ 34 rows in set (0.00 sec)
Also, I am testing on a development server, so there is no activity going on except for my own testing. Therefore there is no activity involving MySQL or Trac other than what I myself am doing. So no possibility of a race condition. But I believe you are thinking about a possible race condition during the full resync, and that is not what is going on here, since the full resync worked, as shown above (no missing records).
This is 100% reproducible with a small database. So is there something else I could look at that might help find the problem for you?
Dennis
P.S. When I go to the MySqlDb page, the two links at the bottom of the MySQLdb section to fix my thread-safe problem are broken. Can you fix them so I can see what is being suggested? Thanks.
comment:4 by , 14 years ago
| Keywords: | weird removed |
|---|---|
| Milestone: | next-major-0.1X → 0.12.1 |
| Owner: | set to |
Dennis sent me a dump of his repository, and I was able to reproduce the problem.
Note that our own svnrepos.dump test repository shows the same problem, when we are scoping it with trunk (well, tête now). We simply never noticed…
The proper way to "fix" this issue would be to do a full resync, along the lines of ticket:5932#comment:23.
As mentioned there, the cause for the problem is quite mysterious, feels like a race condition. However, as this happens during a db transaction, I fail to see how such a race can happen. Except maybe in your case, as you have the mysql bindings which are not compiled in thread_safe mode. Even if it's not the root cause for the present problem, this is bound to cause you other problems, so you'd better fix that anyway (follow the instructions in the MySqlDb#MySQLdb page).