Changes between Version 3 and Version 4 of TracSqlHelperScript
- Timestamp:
- Mar 16, 2015, 7:46:53 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracSqlHelperScript
v3 v4 1 1 [[PageOutline(2-5,Contents,pullout)]] 2 = Helper functions to abstract the Trac SQL API =3 2 4 = = Description ==3 = Helper functions to abstract the Trac SQL API 5 4 6 While there is considerable contention on the subject, I am one of those people that doesn't like to see SQL statements in python code (or C code, etc). I especially don't like it when the same basic statements are repeated all over the place. So TracSqlHelperScript is my attempt to encapsulate all of this logic in one place. These are functions I've already co-written for the TracHoursPlugin and then rewritten (some of them) for the GeoTicketPlugin. Instead of rewriting them again for yet another plugin where I want this functionality, I'm making a library out of them which hopefully I will backport to those plugins. 5 == Description 7 6 8 I'd really like a better story for this in general, like having at least some of these convenient functions on the DB cursor. But quite frankly, I'm not an SQL expert, and IMHO it would be better for Trac to completely abstract its backend, so I'll leave whatever action for those that know better and stick with this library for my purposes.7 While there is considerable contention on the subject, I am one of those people that doesn't like to see SQL statements in python code (or C code, etc). I especially don't like it when the same basic statements are repeated all over the place. So TracSqlHelperScript is my attempt to encapsulate all of this logic in one place. These are functions I've already co-written for the TracHoursPlugin and then rewritten (some of them) for the GeoTicketPlugin. Instead of rewriting them again for yet another plugin where I want this functionality, I'm making a library out of them which hopefully I will backport to those plugins. 9 8 10 == Bugs/Feature Requests == 9 I'd really like a better story for this in general, like having at least some of these convenient functions on the DB cursor. But quite frankly, I'm not an SQL expert, and IMHO it would be better for Trac to completely abstract its backend, so I'll leave whatever action for those that know better and stick with this library for my purposes. 10 11 == Bugs/Feature Requests 11 12 12 13 Existing bugs and feature requests for TracSqlHelperScript are … … 16 17 [http://trac-hacks.org/newticket?component=TracSqlHelperScript&owner=k0s new ticket]. 17 18 18 == Download == 19 [[TicketQuery(component=TracSqlHelperScript&group=type,format=progress)]] 20 21 == Download 19 22 20 23 Download the zipped source from [download:tracsqlhelperscript here]. 21 24 22 == Source ==25 == Source 23 26 24 27 You can check out TracSqlHelperScript from [http://trac-hacks.org/svn/tracsqlhelperscript here] using Subversion, or [source:tracsqlhelperscript browse the source] with Trac. 25 28 26 == Example ==29 == Example 27 30 28 See the GeoTicketPlugin and the TracHoursPlugin for how these functions are used. Essentially, they're to help build new plugins with when you want to have a slightly abstracted database layer.I'd love help with this, if anyone would like to contribute.31 See the GeoTicketPlugin and the TracHoursPlugin for how these functions are used. Essentially, they're to help build new plugins with when you want to have a slightly abstracted database layer. I'd love help with this, if anyone would like to contribute. 29 32 30 == Recent Changes ==33 == Recent Changes 31 34 32 35 [[ChangeLog(tracsqlhelperscript, 3)]] 33 36 34 == Author/Contributors ==37 == Author/Contributors 35 38 36 39 '''Author:''' [wiki:k0s] [[BR]] 37 '''Maintainer:''' ejucovy[[BR]]40 '''Maintainer:''' [[Maintainer]] [[BR]] 38 41 '''Contributors:'''