Jonathan LaCour <[EMAIL PROTECTED]> writes:
> Absolutely. I just never got around to doing this :) I just added
> project and creator indexes all over the place, but haven't really
> thought about any other indexes that I might need to add. Any
> suggestions?
It depends on your queries. I usually have indices for my FKs since sometimes
(a lot of times, in fact) I'm performing JOINs or searching for other
complementary information.
Database optimization is something that is hard to do... Specially when using
just an ORM. You'll have to run some queries by hand and see how they
perform and think if it is needed to optimize something or not. There was one
query I was using that when moved to a different form run 3 times faster. I
also saw things improving a lot with the right indices (even partial indices
might help!) to make me think about using them always when they are needed.
I also have a friend that's been working as a DBA for almost 30 years, so we
always exchange ideas and hints on how to perform some task.
> I just make sure to use issue.set() instead of setting each column in
> separate assignments. I don't like having to call "sync" ... it
> seems ugly.
I agree with you. ;-) It is really ugly.
> Well, the default server that I deploy with is single-threaded (but
> still very fast). However, I do want to disable caching when running
> multiple load balanced instances. I prefer to do this with
> configuration rather than in the code.
IIRC, it is an SQLObject optimization, so you'll have to do that on your
SQLObject model... Database caching in on the other end and it doesn't affect
your code.
> The one place that this would make sense in the current Fast Track code is
> questions/answers. As of right now, there is no way to delete projects at
> all. You can only "archive" them. You can delete questions however, which
> needs to cascade to delete answers. I will look into this.
I was just commenting without thinking about any specific parts...
I also found out that you created your own date formatting function. Is there
any reason not to use tg.i18n.format.format_date? Using it would also improve
your code's I18Nization.
================================================================================
format_date(dt, format='medium', locale=None, time_format='')
Returns formatted date value. Format can be "full", "long", "medium" or
"short".
@param dt: datetime
@type dt: datetime.datetime
@param format: format("full", "long", "medium", "short")
@type format:string
@param locale
@param time_format: standard time formatting string, e.g. H:M
@type time_format:string
================================================================================
By default, locale is set automatically if your application is i18nized.
There are options to format decimals and numbers as well. (Of course, the
corresponding functions to parse those are also available...)
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
