Master/Child DCRs

I am responsible for two templating solutions which were designed before I became involved with this project. One has already been implemented and the other is commencing development. In each solution, zero or more child DCRs of various types are associated with a master DCR. Each parent and child DCR gets its own database identifier and there are no issues maintaining the relationships between the records in the database.

The users have complained about the first solution because it is difficult to determine the relationships between the DCRs using the filesystem - each DCR has its database key in the filename but not the database key of the parent record, so finding the children associated with a parent is near impossible. For various reasons renaming the child DCRs to include the master record identifier may not be an option, but even if the child DCR names did reference the parent it could still be tricky, time consuming and error-prone to locate all the child records (navigate to each child's data directory and look for files with the parent ID). For the existing solution we are considering implementing a CGI or JSP DCT callout in the master DCR that would query the database and provide CCI links to all of the child DCRs. A similar thing could be implemented for the second solution, but another alternative under consideration would be adding fields in the master DCR to contain references to the child DCRs, with a callout next to each to allow edit. In most cases there is either zero or one record of each child type for each master DCR, but there are cases where there are multiple child records of the same type for a single master DCR. This means if we do implement the references to the child DCRs in the master DCT each may have to be contained in a replicant. Some kind of child DCR file naming logic would probably be needed in the master DCR.

I don't think either solution would be (technically) too complicated to implement, but I'm wondering what alternatives I'm not seeing and what's working for other organizations with similar requirements.

One of the issues I can see is how the actual edit links CCIs are implemented in the master DCR. I would like to have the CGI/JSP display standard CCI edit links, but as far as I know these only work for existing DCRs - is there any way to create an edit link that creates the DCR of a given name if it does not already exist? I would prefer to avoid having templates for each child DCR and creating the file system entry myself. Or alternatively is there any way to encode a CCI "newdcr" link in such a way that on save the DCR will be named based on a URL parameter passed in the link? Is there any way FormAPI can access custom URL parameters passed on the standard "newdcr" CCI link (so my FormAPI could automatically name the DCR as needed on save)?

Find more posts tagged with

Comments

Adam Stoller

Am I correct that the master and child DCRs are of different category and/or data-types?

Can you use sub-directories named after the master DCR for the child DCRs?

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

Migrateduser

They are different types in the same category. I'm not sure I'm following your suggestion.

Adam Stoller

So for example, you have:

templatedata/C1/DT1/data/master_01.dcr
templatedata/C1/DT1/data/master_02.dcr

templatedata/C1/DT2/data/master_01/child_01.dcr
templatedata/C1/DT2/data/master_01/child_02.dcr
templatedata/C1/DT2/data/master_02/child_01.dcr
...

I'm not sure if this works for your environment - but I figured it was worth tossing in as a possible solution.

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

Migrateduser

Yeah thanks that might help, it's certainly an option I hadn't considered (users shouldn't rename the DCRs).

Still looking for suggestions - I think there must be many projects with similar requirements.

iwovGraduate

When you say its difficult to find relationship from filesystem, is it browsing the "data" directory in the TS GUI or IFS (using Windows explorer or something similar) ? I assume its through the GUI since you dont want your users to edit the DCR XML using text editors via IFS.

You can have a menu item: Select the DCR, invoke menu item. The menu item will read the ID of the selected DCR and get all its child DCRs. Assuming that you also store ID and vpath in the DB, you can create CCI links for the list of DCRs in search results. This way you don't have to worry about maintaining a strict directory structure. I would do it (something similar to what ghoti suggested) anyways.

Thats all no biggie. Now, the big question: What is the current or required process by which DCRs and the relationships are created and subsequently stored in the DB? Are there any restrictions/requirements around it or you are looking for the best/most user friendly way to do it? If your process is to first create the (child) DCR, and then add a link to the parent DCR, you don't have to worry about mixing up the CCI links for edit/create. Use browse button on a parent DCR to select vpath to child DCR, callout to edit. Or maybe you can make the callout a little smart to check if the the vpath is a valid file and if not, prompt the user to create one. Another way *might be* to make the callout create a valid XML with no fields, set ext attributes prior to opening the CCI link for edit. You can put the logic to come up with a filename in the callout.

Here is an example of something similar that I worked on a few years ago:
Each DCR corresponds to a product and has all the product details. Each DCR also has a replicant for related products, which contains one field - vpath to another DCR. DAS was used to export the relationships to a DB. Using DAS made certain things easy as there was a need to perform validations against the STAGING and Workarea views of the relationships.

Its rather unfortunate that Templating does not support maintaining relationships among DCRs. This has come up many times in the past. Something for J **** to think about Smiley Happy

gzevin

Its rather unfortunate that Templating does not support maintaining relationships among DCRs. This has come up many times in the past. Something for J **** to think about Smiley Happy

in general, it shoud be a tight coupling of DCRs and database... but I think the problem is the underlying file system (backing store)....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Someone on the Yahoo group suggested using extended attributes on the parent DCR to reference the children. Apparently in 6.x you can access (set?) extended attributes using FormAPI instead of writing custom CGI/JSP to do this.

Users should never come through the IFS, always through the browser. They don't really object to all the file system navigation (which I would somewhat expect), it is really determining which DCR to work with once they get there that is the problem. I think in the long run it may be better to avoid clicking around for the child DCRs entirely.

Unfortunately the database does not currently have a column for the vpath of the DCR, but I am trying to get the DBA to add that to the custom loader.

We will probably end up with some kind of hybrid solution incorporating the ideas here, but there must still be some ideas we haven't heard - again, don't dozens of customers have issues like this? I can't believe everyone would put the burden on the users...

To my knowledge the process is always to create the master record, then the child record. I have to assume that there could be multiple users involved, which is one reason why everything isn't just in one big DCR (along with performance). So users could either create a master DCR and create children from there (using the custom menu item, but I would prefer they do everything from the data capture form itself), or they could create child records and select the master DCR to associate with them, but in either case the master must exist first. I am looking for the best and most user-friendly way to do this - this is a new system for them so the business process is not set in stone.

The thing is, it seems like an easy thing to add to the product that would add a lot of value - don't get everything from the database but have some kind of locally or globally unique sequence(s), and a little joining code. It's unfortunate to see so many organizations have the the same problems.