On Monday, March 17, 2014 5:40:34 PM UTC-7, ONeal Freeman wrote: > > > > On Monday, March 17, 2014 7:32:00 PM UTC-5, RjOllos wrote: >> >> On Monday, March 17, 2014 5:29:51 PM UTC-7, ONeal Freeman wrote: >>> >>> >>> >>> On Monday, March 17, 2014 7:24:58 PM UTC-5, RjOllos wrote: >>>> >>>> On Monday, March 17, 2014 5:14:12 PM UTC-7, RjOllos wrote: >>>>> >>>>> On Monday, March 17, 2014 5:04:04 PM UTC-7, ONeal Freeman wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Monday, March 17, 2014 4:51:20 PM UTC-5, RjOllos wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, March 17, 2014 2:34:12 PM UTC-7, ONeal Freeman wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Monday, March 17, 2014 4:15:46 PM UTC-5, RjOllos wrote: >>>>>>>>> >>>>>>>>> On Monday, March 17, 2014 2:12:17 PM UTC-7, ONeal Freeman wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Monday, March 17, 2014 1:11:28 PM UTC-5, RjOllos wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Monday, March 17, 2014 9:29:56 AM UTC-7, ONeal Freeman wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Saturday, March 15, 2014 5:40:29 PM UTC-5, RjOllos wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Saturday, March 15, 2014 12:48:07 PM UTC-7, hasienda wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>>>> Hash: SHA1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 15.03.2014 17:55, ONeal Freeman wrote: >>>>>>>>>>>>>> > Good in theory but it did not work in my case since >>>>>>>>>>>>>> something during the >>>>>>>>>>>>>> > trac-admin upgrade command is wiping out some rather >>>>>>>>>>>>>> important db >>>>>>>>>>>>>> > fields. Now that's not to say that I do not have something >>>>>>>>>>>>>> > mis-configured. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is this 'something' that is worrying me. Granted that Trac >>>>>>>>>>>>>> upgrades >>>>>>>>>>>>>> are solid and reliable, million times tested process it is >>>>>>>>>>>>>> unlikely, >>>>>>>>>>>>>> that just you'll get hit by a flaw. Experiencing issues I >>>>>>>>>>>>>> would repeat >>>>>>>>>>>>>> the process with all plugins disabled/uninstalled and just >>>>>>>>>>>>>> upgrade Trac >>>>>>>>>>>>>> core, upgrade plugins later on, if required. >>>>>>>>>>>>>> >>>>>>>>>>>>>> > This is my first dealing with Trac from this >>>>>>>>>>>>>> > prospective. Since I never got the tractickettemplateplugin >>>>>>>>>>>>>> to work I am >>>>>>>>>>>>>> > wondering if all of this is associated with the BitNami >>>>>>>>>>>>>> install of Trac. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nothing special with BitNami's stack as far as I know from >>>>>>>>>>>>>> using it two >>>>>>>>>>>>>> times on WinXP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Again, I am a novice but I have definitely learned a lot. >>>>>>>>>>>>>> Please don't >>>>>>>>>>>>>> > take any of this wrong, I sincerely appreciate you guys >>>>>>>>>>>>>> helping me and >>>>>>>>>>>>>> > your assistance has gotten me this far. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sure, you're welcome. Still i hope, that we'll finally get a >>>>>>>>>>>>>> clue, what >>>>>>>>>>>>>> is going on. Did we talk about DEBUG logs from upgrade >>>>>>>>>>>>>> process yet? >>>>>>>>>>>>>> Mysteries in code do not any good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Steffen Hoffmann >>>>>>>>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>>>>>>>> Version: GnuPG v1.4.12 (GNU/Linux) >>>>>>>>>>>>>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> iEYEARECAAYFAlMkrnUACgkQ31DJeiZFuHdafACdGG8Kl+m8OtsnFNNV/mN2u4Mf >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2YoAnjVbYgp3shiZQ0/J+DJzhEjorv1/ >>>>>>>>>>>>>> =6ehf >>>>>>>>>>>>>> -----END PGP SIGNATURE----- >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've tested with Bitnami Trac and can't reproduce the upgrade >>>>>>>>>>>>> issue. I think the only thing left is to look at the database in >>>>>>>>>>>>> which the >>>>>>>>>>>>> upgrade doesn't seem to have gone correctly. >>>>>>>>>>>>> >>>>>>>>>>>>> I see now that my manual import of data into the trac.db has >>>>>>>>>>>> distorted the ticket descriptions formatting. Whereas in the >>>>>>>>>>>> original trac >>>>>>>>>>>> instance I had line feeds between the different sections the data >>>>>>>>>>>> import >>>>>>>>>>>> eliminated the line feeds and now the text is end to end like in >>>>>>>>>>>> notepad. >>>>>>>>>>>> >>>>>>>>>>>> Steffen told me it was a bad idea to do a manual update. I just >>>>>>>>>>>> couldn't figure out another way to retrieve my time and timechange >>>>>>>>>>>> fields. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Have you tried using the trac.db file that I sent back to you? >>>>>>>>>>> The database appears to have been upgraded without any issues and >>>>>>>>>>> you could >>>>>>>>>>> just discard that instance that you manually tweaked. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sorry, I missed the db you sent. Never got any type of >>>>>>>>>> notification. >>>>>>>>>> >>>>>>>>> >>>>>>>>> That is strange. I received a notification when receiving the file >>>>>>>>> you sent, so I assumed you'd receive the same style notification. >>>>>>>>> >>>>>>>>> You should be able to access it here: >>>>>>>>> https://drive.google.com/file/d/0B6br6SyRs711OG1sTjNjRXFYVmM/edit?usp=sharing >>>>>>>>> >>>>>>>>> Let me know if you encounter any problems. >>>>>>>>> >>>>>>>> >>>>>>>> Downloaded the db. The same fields are still empty... >>>>>>>> >>>>>>> >>>>>>> How did you determine that they are "empty"? I pulled the file off >>>>>>> Google drive, dropped it into a Trac 1.0.1 instance and they certainly >>>>>>> aren't empty. The ticket created, modified and change timestamps are >>>>>>> displaying correctly. There must be something else going on here. >>>>>>> >>>>>>> >>>>>>> <https://lh3.googleusercontent.com/-vFgrLhpR48Y/UyduN_1QEdI/AAAAAAAABLw/52WgjaOIccE/s1600/Untitled.png> >>>>>>> Does the attached query return any results for you? >>>>>>> >>>>>> >>>>> No, but I will assume that the query is just incorrect. >>>>> >>>>> Have you tried putting the trac.db file I sent into your Trac >>>>> instance? >>>>> >>>> >>>> And besides the possibility that the query is incorrectly, the most >>>> recent activity in the timeline is May 2, 2013, ticket #5246. >>>> >>>> Btw, the timestamp fields are not "unixepoch", which is number of >>>> seconds since the Epoch. Since Trac 0.12, the fields are "number of >>>> microseconds since the epoch": unixepoch * 1e6. >>>> >>>> I did drop it in to my trac instance but I cannot tell a difference. I >>>> will look at correcting the query. >>>> >>> >> Earlier I showed you a screen capture of ticket #519 that displayed: >> "Opened 6 years ago", "Last modified 4 years ago". What does ticket #519 >> display in your Trac instance? >> > > shows the same >
So what is the actual problem you are experiencing? Clearly the data is not empty or zeroed-out. I also looked at the trac.db you sent with the message "trac db with upgrade issue". The timestamps are in the normal range, with activity in 2013-2014. They certainly aren't empty or zeroed out. It appears the issue here is simply that you are mis-interpreting what is stored in the database for the time fields. There is no issue with the upgrade or the data in the database. As Chris mentioned, you may need to rewrite some of the non-portable SQL queries in your reports. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
