On 21/08/09 6:19 AM, Bart Ogryczak wrote: >>> What are the best practices concerning this? >>> First the tables. Is there any standard when the should be created? In >>> the setup script? Some 'first-run' script? >> >> Here is a quite clean implementation you could 'borrow' - i'm still at >> version 1 of db schema, so it just has placeholders for future >> upgrades which also needs to be handled gracefully: >> >> http://trac-hacks.org/browser/fullblogplugin/0.11/tracfullblog/db.py > > Nice, but has downside -- causes the Trac to go off-line with message > about needing env upgrade. I'd rather have the environment set up > while installing the .egg.
It's pretty clean, but there are a number of improvements that I would suggest as a part of best practices and some further refinement. 1. Lacking db.commit so this has high failure potential on postgres, especially when you start doing upgrades 2. Lacking error handling and logging, e.g. use db.rollback 3. Doesn't create it's tables during environment_created, thus requiring the upgrade to be done manually after creating an environment. 4. no indexing on the tables (I haven't looked at all the sql to see whether it is really necessary, but I'm sure it is) 5. it's hard to tell from the table layout how the comments are linked to the blog posts from the table layout, but if you use string comparison, switch to integer id fields, int comparisons are faster. 6. _get_version has a log.debug, get rid of that, the output is not useful. Shane --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
