-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terje S. wrote: [...] > Thanks everyone for your time, I have gathered the information I was looking > for. I am sad that noone spoke up in favour, and will now stop beating the > topic further to death. Let me know if any modelling work is needed. > > At least I tried..
Don't let this be your last word on this topic. I consider myself a small contributor, being a Trac admin and user for about a year now as well. And I did not even dare to wrap my mind around Trac's data storage structure after having a first look, because I thought it would take too much time and I had no pressing need to spend that time either. So by now I just know enough to get some plugin stuff to work with ticket and ticket_custom table, and that's all. That said I like your idea about bringing Trac's database to a (more) relational structure. Even if I'm not remotely trained to do i/o related programming with Python, I wouldn't mind lending a helping hand for testing. I'm maintaining and further developing my Trac applications to (ab?)use Trac far away from software development for issue tracking in non-software project management and even as a highly configurable distributed enterprise logbook. I don't speak of a couple of issues and some dozen comments per day but something like around 200 tickets per hour(!) and searching the ticket summary of the whole archive for at least 10 years back. Will test this with 0.12 soon. But I guess that afterwards I'll be not less eager to push the idea here at least up to the proof-of-concept for showing how (much) the more generic approach to database schema design would serve for one use case or another (mine). Let me add a strong BUT now, since the initial post was not that strong about the foreseeable migration path. I wouldn't even think about any new Trac version that I couldn't upgrade to as I did by now. And I guess there is a considerable number of Trac application that do as I do: stick with default SQLite database since the upgrade to next Trac version is guaranteed to work like a charm, so no need to become a real DB admin just to handle Trac. The automatic upgrade should be a must-have for any change and I urge you to not underestimate that point. Sincerely Steffen Hoffmann (hasienda) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkw1Ao8ACgkQ31DJeiZFuHdcLQCfSFV2MqvfDOcd0ccBL9SnkA8H q2oAn2YK9dJxLgnH7Pz6bl/20HxIRbeV =pT3D -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
