Change component DCR Regenerate References

Hello,

I'm using 5.5.2 and upgrading soon. I have a situation where many Templating Data Types in our installation propduce DCR's that contain references to other DCR's whos content is shared accross many different Templated pages and is pulled in during page regeneration.

I am trying to solve the issue of how to automate the generation of all the pages where the shared content component is used when the shared content component is updated.

I have developed a script which searches through all the DCR's of specified Data Types and searches for references a DCR file name which is passed as a parameter. The search results are then stored in an array. It then searches through the files on the site and regenerates the pages whos Templating/PrimaryDCR matches the DCR's found in the DCR search.

We're currently using just standard submit workflow or a slightly modified version. Workflow and its use here is small.

My current questions are:

What is the best way to initiate this find and regenerate script?

Custom Menu Item? If so I would like to display the results of the search and which files were generated. How do I do this from a CGI perspective?

Workflow?

Any ideas or thoughts would be great.

Thanks,

- Tim

Find more posts tagged with

Comments

Migrateduser

If I were doing this, I would go with a workflow approach. I figure I'd also track the related files via either an extended attribute or, if that gets kinda hokey, a flat text file somewhere that can be searched very easily by Perl. If you have access to a database with this thing and you feel like scaling it up, that would be even better.

Dave

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
(3) TS 6.1 on W2K

Tim__D

The thing I think about with EA's is that I dont see how they get merged. Lets say one of my Parent DCR's has a replicant with a ordered list of refernces to other DCR's (inserts are one example). If these values are stored in an EA and the value needs to be merged with another branch that conflicts that could get sticky. I dont believe EA's can be merged.

The issue with the DB is similar I dont think my org is ready to deal with a content database. There is a ton of concurrent development happening here and the managment of a single content DB serving multiple branches could get hairy.

- Tim

Adam Stoller

from the description given, I'd second the idea of using a DB. When you push things out to the web site, use DD to store the relationships into the DB, and then use whatever you want (workflow, custom menu item, or nightly cron job) to check the timestamps on the common files and query the DB for all files that utilize that data which were last generated before the last change to the common files.

Take some time to figure out all the relationship and date information you need to do all this so that you can make sure you get it all entered into the DB.

You'll also probably want to write a bootstrap script to traverse through the TeamSite file system and perform an initial population of the DB.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Tim__D

If I did use a DB could it reside in each branch? A central DB may not work for all the concurrent development happening here.

Migrateduser

A database residing in each branch? I imagine that would be a concurrency nightmare versus having one central database. Concurrent development really shouldn't be a concern against using a database -- actually, it should be an incentive. You could design some small relational schema, store your queries as stored procs, and lock and unlock the tables as you query them, if desired.

Dave

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
(3) TS 6.1 on W2K

Tim__D

We're not using data deploy either. Is it difficult to implement? The thing is that one Parent DCR could have up to 4 different sets of replicants or other fields that point to related DCR's. Does that make deploying the information to the database more difficult?

Migrateduser

DataDeploy is not necessary for what you need to do, as I see it. If you're taking the workflow approach, this might be greatly simplified. Your first externaltask immediately after saving this DCR might be to query the database and insert/update whichever necessary tables are involved in your DCR. You could create a Perl module to create the connection and create stored procs to do the dirty work. This way, your code is reusable, your database is less bogged down, and concurrency shouldn't be an issue.

Dave

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
(3) TS 6.1 on W2K

Tim__D

Thanks everyone for your feedback.