On May 31, 6:16 pm, "Andrew Scott" <[EMAIL PROTECTED]> wrote: > Correct me if I am wrong and the Farcry code makes me think that I am > correct, and if a developer of farcry comes to me and says that you can > truncate the dmArchive and then in the same breath, say that the orphaned > files should not be an issue and then provide feedback on what to do to get > rid of it. In my opinion, I got the answer.
Orphaning records is *not* something we advocate. It is important to understand that orphaning records in this sceanrio will not cause the system to fail -- it gives you options for approaching the task at hand. You have chosen to interpret this statement as a recommendation. It was not. There is a tool designed to clean up orphans in refObjects. Removing orphans is a common requirement if you are migrating, truncating or otherwise bypassing the application framework to manipulate the underlying data model. We built this tool specifically to address this issue as we do *not* advocate leaving orphaned references in the system. I understood you needed to truncate records in a hurry and get your database into a manageable state. Therefore, I outlined a perfectly adequate and immediate response for the scenario. It's unfortunate that my best intentions have been so misconstrued. > Jason I am not going to discuss this with you anymore, the fact is what I > asked for was not fully given and I had to again ask if it was ok to delete > the entries in the refObjects table that have the same ObjectId as the > archiveId in the dmArchive table, when that was in my first post to start > with. This is not correct. And is one of the reasons this was not part of my response. The relationship between refObjects and all content type tables is based on objectid and *not* dmarchive.archiveid. archiveid is a reference to the live content object that is currently being versioned. It is not the primary key of the dmarchive table. If you are deleting objects from dmArchive table then you need to remove records from refObjects that match refobjects.objectid to dmArchive.objectid and are of typename "dmarchive". Removing references that match dmarchive.archiveid to refobjects.objectid will corrupt the refobjects table. Finally, I would not recommend the periodic truncation of the dmArchive table based on a simple timestamp as a matter of course. These records represent the ability to "roll back" to previous iterations of a piece of content. Just because an archive is older does not mean it is less important. It would be better to attempt to limit individual content items to a set number of roll back points. For example, each content item can only have a maximum of 3 archives. Regards, -- geoff http://www.daemon.com.au/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "farcry-dev" 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/farcry-dev?hl=en -~----------~----~----~----~------~----~------~--~---
