Oops wrt datetime function when using TicketModifiedFiles

text output from oops

Thank you for your error report... In fact, searching on the web a few days ago, I found this link: http://groups.google.gp/group/trac-users/browse_thread/thread/269e545ceb323679/5d16b9471a0c1afd?hide_quotes=no&fwc=1

It report the same problem, while executing this query:

cursor.execute("SELECT rev, datetime(time, 'unixepoch', 'localtime') as date, author, message FROM revision WHERE message LIKE '%#" + str(id) + "%'")

On this page, I clearly see that this person is using MySQL (MySQL: server: "5.0.45-community", client: "5.0.45", thread-safe: 0 MySQLdb: 1.2.2 )

Are you also using MySQL? I have only been able to test the plugin using a SQLite database, so I guess the datetime() is creating the problem...

If you could please confirm that you are using MySQL, and I will do the necessary to make the code MySQL-compliant (in fact, this query is not 100% necessary, as it only provides the time of the commits related to this ticket...)

I am using postgres on rhel. ty for your quick reply.

I am currently using an ugly textarea custom ticket field to store this data. Where are you storing the list of mod files?

Yes, I guess datetime() is only available on SQLite, neither on MySQL nor Postgres... I'll fix this tomorrow at work.

Concerning the previous comment, I guess you wanted to know where I store the list of modified files? Well, that's the whole point of this plugin, I don't store the info of the modified files, I get it directly from the database! This enables to see if there are other (not-closed) tickets that have modified the same files...

Replying to e2jk:

Yes, I guess datetime() is only available on SQLite, neither on MySQL nor Postgres... I'll fix this tomorrow at work. Concerning the previous comment, I guess you wanted to know where I store the list of modified files? Well, that's the whole point of this plugin, I don't store the info of the modified files, I get it directly from the database! This enables to see if there are other (not-closed) tickets that have modified the same files...

Does it make sense to use your plugin without svn? I am not that organized yet and none of my source is in a repo. I have some db components that change frequently and haven't figured out a way to version them yet.

I also installed this plugin today and also got the OOPS display. This is the setup I am using on a Linux processor:

System Information
Trac: 	0.11.1
Python: 	2.5.1 (r251:54863, Sep 21 2007, 22:46:31) [GCC 4.2.1 (SUSE Linux)]
setuptools: 	0.6c8
MySQL: 	server: "5.0.45", client: "5.0.45", thread-safe: 0
MySQLdb: 	1.2.2
Genshi: 	0.5.1
mod_python: 	3.3.1
Subversion: 	1.5.2 (r32768)
jQuery:	1.2.6

To stop the OOPS display I removed the plugin from the trac/plugins directory and removed the entry from the trac.ini file. I also had to restart my apache2 server.

Must I restart the apache2 server after I install the plugin? I assume "yes" from what I have seen. I will check back for an updated revision to install and let you know the results. Thank you. dale.miller@ngc.com

Replying to anonymous:

Must I restart the apache2 server after I install the plugin? I assume "yes" from what I have seen. I will check back for an updated revision to install and let you know the results. Thank you. dale.miller@ngc.com

The rule of thumb I use is if you edit trac.ini, then apache must be restarted.

OK, so I finally found the time to modify the ticket. I removed the SQLite specific query and replaced it with a more generic query. Now the plugin should function normally with any database supported by Trac.

Please install this new version:

easy_install http://trac-hacks.org/svn/ticketmodifiedfilesplugin

and restart your Apache/tracd server.

Let me know if it works!

Replying to anonymous:

Does it make sense to use your plugin without svn? I am not that organized yet and none of my source is in a repo. I have some db components that change frequently and haven't figured out a way to version them yet.

Well, this plugin uses the information from the database to determine which files have been modified, and which tickets are in conflict. The database is related to your svn activity, so I would say the plugin has no use if your project is not version controlled.

I don't know what your problem exactly is, but I would say that you could version your project and leave the db components (what are they, database backups?) out of the svn repository. That way your source files are "versionned" and you can use Trac and this plugin to it's full extent.

When you get some time to get organized, you'll see it really is worth the trouble setting up a version control system, it really eases the development process. I hope you'll find this precious time!

Replying to e2jk:

Well, this plugin uses the information from the database to determine which files have been modified, and which tickets are in conflict. The database is related to your svn activity, so I would say the plugin has no use if your project is not version controlled. I don't know what your problem exactly is, but I would say that you could version your project and leave the db components (what are they, database backups?) out of the svn repository. That way your source files are "versionned" and you can use Trac and this plugin to it's full extent.

I guess you could say the location that our database (Unidata) stores schema, stored procedure, and 4gl screen data is a binary file. For example, the DATA section of the ORDER file is binary (and that is ok). The DICT section of ORDER contains field definitions, System Builder Reports, System Builder Screens, etc. A really good FUSE driver would make all of this work, unfortunalty, its running on AIX, not Linux. So a metric ton of my BI is stored in 100-125 binary files.

When you get some time to get organized, you'll see it really is worth the trouble setting up a version control system, it really eases the development process. I hope you'll find this precious time!

I agree.

Replying to anonymous:

Have you found the time to install the new version of the plugin? I know it will not be really useful to you, but at least we will be able to know if the plugin works with a Postgres Database, which was the original problem...

Please keep me posted!

Replying to e2jk:

Replying to anonymous: Have you found the time to install the new version of the plugin? I know it will not be really useful to you, but at least we will be able to know if the plugin works with a Postgres Database, which was the original problem... Please keep me posted!

Does the zip file url resolve to this new version? Our web filter (or some other probem) does something to spoil easy_install for me. I usually wget the zip version of plugins from t.h.o

Replying to anonymous:

Does the zip file url resolve to this new version? Our web filter (or some other probem) does something to spoil easy_install for me. I usually wget the zip version of plugins from t.h.o

Yes it does, the zip always points to the latest svn version!

It installs cleanly and looks good.

Would it be possible to consider a non-svn mode that just prompted the user for one-line free form text, and merely inserted it into the same sql table.

That would meet my current immature SCM needs.

The table would need 3 controls, add/change/delete.

Replying to anonymous:

It installs cleanly and looks good. Would it be possible to consider a non-svn mode that just prompted the user for one-line free form text, and merely inserted it into the same sql table. That would meet my current immature SCM needs. The table would need 3 controls, add/change/delete.

Of course I mean the ability t insert several one-liners per ticket. SOme of my 4gl screen projects will touch 3 schemas, 1 screen, 12-15 field definitions. I track them all manually right now.

Thank you for making the update. I will download it and install it. I am interested to see how it works.

The description on the TicketModifiedFilesPlugin page still shows

Latest version: 0.9 (24/07/2008).

It should be updated to reflect the new version.

Replying to anonymous:

It installs cleanly and looks good. Would it be possible to consider a non-svn mode that just prompted the user for one-line free form text, and merely inserted it into the same sql table. That would meet my current immature SCM needs. The table would need 3 controls, add/change/delete.

I can understand your needs, but I'm afraid I will not modify this plugin to function in non-svn mode: one of the main reason being that this plugin is made to extract information available in the database, not write in this database...

I can only encourage you to try to version-control your project?

Replying to dale.miller@ngc.com:

Thank you for making the update. I will download it and install it. I am interested to see how it works. The description on the TicketModifiedFilesPlugin page still shows {{{ Latest version: 0.9 (24/07/2008). }}} It should be updated to reflect the new version.

OK, update done! Keep me informed if the plugin works for you too!

It is working. I like what it does. It does affect the display time on some tickets but that is to be expected for tickets where many commits have been entered and many of the files have been cross listed in many tickets.

The "Warning" and "conflicts" wording may be a bit strong but once I explained to the team what this plugin does they were okay.

Example:

Warning: There are 48 tickets that are in conflict with this one!

The above ticket takes about one second to display.

I like the fact that you added the "Change History" block with the basic information and the links to getting the complete information.

Well, it is true that the words may ne a bit strong, but this is due to the fact that I work in a web company, and we can absolutely not upload files that are "in conflict", because you have to upload bug fixes in their entirety, not just part of it, so for instance when you upload a bug fix that has necessitated the modifications of 5 files, but one of these files have been modified to resolve another bug, you can not upload this bug fix before the conflict is corrected... That's why those words where chosen, but I am aware that they may not apply as strongly by other companies.

Of course, a ticket that has a lot of modifications (and a lot of conflicts) requires a lot of DB queries (get all the ticket's modifications, then for each modification look in the database if another ticket has modified the same file, get file status, etc.)

Our development procedures intend to favorite small tickets, so that they can be resolved and closed faster. Of course, larger tickets exists as well (for example, change the way the images are stored in the database), and implicate more conflicts. But I must admit that I've never had as many as 48 conflicts! I guess 8 ior 9 was our record ;)

Thanks for the update, and I hope this plugin will be useful to you!

Replying to e2jk:

Replying to dale.miller@ngc.com:

Thank you for making the update. I will download it and install it. I am interested to see how it works. The description on the TicketModifiedFilesPlugin page still shows {{{ Latest version: 0.9 (24/07/2008). }}} It should be updated to reflect the new version.

OK, update done! Keep me informed if the plugin works for you too!

I replied to you off-line, at the email add stored in the wiki. :)

Replying to anonymous:

Replying to e2jk:

Replying to dale.miller@ngc.com:

Thank you for making the update. I will download it and install it. I am interested to see how it works. The description on the TicketModifiedFilesPlugin page still shows {{{ Latest version: 0.9 (24/07/2008). }}} It should be updated to reflect the new version.

OK, update done! Keep me informed if the plugin works for you too!

I replied to you off-line, at the email add stored in the wiki. :)

e2jk, the email add listed in the wiki bounced. Can I ask you an offline question about the plugin? If its ok, pls contact me at sromanow at commercecorp.com