"Pre-computing"

Jaredc brought up a great idea about storing a page’s genealogy as a column in the table. Remon likewise had a great idea to "automate" more of the cache handling by comparing timestamps. Both of these ideas are a way I’m referring to as "pre-computing" things that normally would have to be queried and then compared or iteratively looped through to determine how to handle situations.

What else could we lump in similar buckets?

Quote from: rthrash at Nov 16, 2005, 02:29 PM

Jaredc brought up a great idea about storing a page’s genealogy as a column in the table. Remon likewise had a great idea to "automate" more of the cache handling by comparing timestamps. Both of these ideas are a way I’m referring to as "pre-computing" things that normally would have to be queried and then compared or iteratively looped through to determine how to handle situations.

Before I come up with new ideas, I just want to mention if we handle the pre-computation in conjunction with our caching mechanism, we can further extend the capabilities of the system, and the ability to keep the site running even when the DB is down (something I frequently deal with when using any database-driven web application). For instance, check for cached geneology and if it doesn’t exist, then use the database information persisted for the document OR calculate the geneology dynamically (if not specified) to update the cache, before finally making the information available to the API or parser. If the DB is down, then we depend on the cache. Thoughts?

Sounds like a much more robust implmentation. I love that. Marketing wheels start turning:

NEW! Handles database failures gracefully -- the robust MODx caching system keeps your site up when your database fails. This means that sites deployed on potentially overloaded shared servers can offer a better end-user experience by never showing database failure messages on the front end (but they’re always logged on the back end)!

:)

We could tear out the export site to HTML all together.

What would be really cool too would be if you could have an automatic friendly erorr message that would show up in the place of the "no cache" snippets.

Quote from: aNoble at Nov 16, 2005, 03:07 PM

We could tear out the export site to HTML all together.

How would that save cycles or DB queries... does it insert overhead anywhere if it’s not used?

What would be really cool too would be if you could have an automatic friendly erorr message that would show up in the place of the "no cache" snippets.

Can you explain a bit more what you mean here, please? I’m feeling a bit dense today... :/

Quote from: aNoble at Nov 16, 2005, 03:07 PM

We could tear out the export site to HTML all together.

I think we definitely need to improve this, but exporting site functionality should be extended IMO, to export to a usable static HTML snapshot of the site, with all needed resources. But that’s a whole other ballgame. I do not think the caching would replace this capability.

Quote from: aNoble at Nov 16, 2005, 03:07 PM

What would be really cool too would be if you could have an automatic friendly erorr message that would show up in the place of the "no cache" snippets.

That or the previously rendered output from the snippet the last time it could contact the DB.

Quote from: OpenGeek at Nov 16, 2005, 03:29 PM

I think we definitely need to improve this, but exporting site functionality should be extended IMO, to export to a usable static HTML snapshot of the site, with all needed resources. But that’s a whole other ballgame. I do not think the caching would replace this capability.

Just a joke really but we do need to turn the HTML export into a module.

Quote from: OpenGeek at Nov 16, 2005, 03:29 PM

That or the previously rendered output from the snippet the last time it could contact the DB.

We could, but I’d rather throw a friendly error. IMHO it’s better to say "The search form isn’t working rigth now." than to have people typing in searches and never getting anything back.