Custom Query (1173 matches)
Results (151 - 153 of 1173)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #142 | fixed | Make sure we're using 100% efficient queries / indexes | ||
| Description |
Every query we use should be able to efficiently use an index, yet
at the same time, we shouldn't create superflous indexes.
Related:
- `http://kylebanker.com/blog/2010/09/21/the-joy-of-mongodb-indexes/ <http://kylebanker.com/blog/2010/09/21/the-joy-of-mongodb-indexes/>`_
- `http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ <http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ>`_
- `http://www.mongodb.org/display/DOCS/Indexes <http://www.mongodb.org/display/DOCS/Indexes>`_
Especially, we should play with using explain:
`http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-Use{{explain <http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-Use%7B%7Bexplain>`_}}.
Assigning to myself, but feel free to claim this if you're excited
about investigating.
|
|||
| #150 | FIXED | Set deprecated indexing back to keeping index information | ||
| Description |
When you create an index in indexes.py it's like:
::
USER_INDEXES = {
'username_unique': {
# Index usernames, and make sure they're unique.
# ... I guess we might need to adjust this once we're federated :)
'index': 'username',
'unique': True},
'created': {
# All most recently created users
'index': 'created'}}
However when you remove it, we just keep track on the key/name
there (like 'username\_unique' and drop the rest of the info
because it isn't immediately needed.
::
DEPRECATED_USER_INDEXES = ['created']
... that's a shame because then we might forget what the original
index was, and all that useful information. Even though that's not
needed, we should keep it around.
I originally wrote the code to be like that, then I changed it.
Time to change it back!
|
|||
| #154 | FIXED | util.py is cluttered | ||
| Description |
mediagoblin/util.py is like our junk drawer for any functionality we want to abstract out of a particular view, and it's starting to get ugly. At present, it contains methods related to: testing, templating, request processing, user sessions, dynamic component importing, urls/slugs, email, translation, data sanitizing,and pagination. Most of these categories are functionally distinct from the others and could be separated out into different files according to category, e.g.: mediagoblin/tools - tests.py - templates.py - requests.py - text\_processing.py - etc. Once a structure is decided upon, imports referencing util.py will have to be updated. |
|||
Note:
See TracQuery
for help on using queries.
