Hi Clark, I got it. Thanks.
Helen On Oct 11, 2010, at 3:21 PM, Clark Richey wrote: > You already had one good use case where it won't be possible to do > consolidated search. Additionally, you are complicating the process of > promoting an article from staging to production as you now need to copy the > article to a new database. Having separate databases is a great tool when you > have different indexing settings that you need to apply or content that is > not related. As that isn't the case in your situation you are now just adding > to the amount of configuration work you are going to have to do in keeping > the settings for both databases in sync. Can it be done? Sure but you aren't > gaining anything and it is going to take additional work to create and > maintain and it introduces additional places where error can creep in. > > ---- > > Clark D. Richey, Jr. > Principal Technologist, Federal > Mark Logic Corporation > 1600 Tysons Blvd > Suite 835 > McLean, VA 22102 > Phone: 240 - CLARK - 07 > (240 - 25275 - 07) > > > clark.ric...@marklogic.com > > www.marklogic.com > > This e-mail and any accompanying attachments are confidential. The > information is intended solely for the use of the individual to whom it is > addressed. Any review, disclosure, copying, distribution, or use of this > e-mail communication by others is strictly prohibited. If you are not the > intended recipient, please notify us immediately by returning this message to > the sender and delete all copies. Thank you for your cooperation. > > > > > > > On Oct 11, 2010, at 3:16 PM, helen chen wrote: > >> So one database is better. Can you give me some example that why separate >> database will be more trouble? I just want to understand more. >> >> Thanks, Helen >> >> >> On Oct 11, 2010, at 3:07 PM, Clark Richey wrote: >> >>> I would recommend a naming convention that indicates production vs. staging >>> articles. You could do this in conjunction with, or without, the use of >>> collections. >>> >>> ---- >>> >>> Clark D. Richey, Jr. >>> Principal Technologist, Federal >>> Mark Logic Corporation >>> 1600 Tysons Blvd >>> Suite 835 >>> McLean, VA 22102 >>> Phone: 240 - CLARK - 07 >>> (240 - 25275 - 07) >>> >>> >>> clark.ric...@marklogic.com >>> >>> www.marklogic.com >>> >>> This e-mail and any accompanying attachments are confidential. The >>> information is intended solely for the use of the individual to whom it is >>> addressed. Any review, disclosure, copying, distribution, or use of this >>> e-mail communication by others is strictly prohibited. If you are not the >>> intended recipient, please notify us immediately by returning this message >>> to the sender and delete all copies. Thank you for your cooperation. >>> >>> >>> >>> >>> >>> >>> On Oct 11, 2010, at 2:18 PM, helen chen wrote: >>> >>>> At some point I may have this situation: the article that is in production >>>> stage, but there may be some very minor fix, and they don't want to pull >>>> it out from production, so they just load another version into staging, >>>> after verification, it will move to production again to replace the old >>>> one. In this situation I will have a very small window that one article >>>> will be in two versions and in both stage. And I need to keep the uri >>>> separate so I can hold different versions. >>>> >>>> Is there any suggestions on how to handle this situation? >>>> >>>> Thanks, >>>> Helen >>>> >>>> >>>> >>>> >>>> On Oct 11, 2010, at 2:08 PM, Zegarek, Arthur wrote: >>>> >>>>> We do exactly that and use collections – it works well >>>>> >>>>> From: general-boun...@developer.marklogic.com >>>>> [mailto:general-boun...@developer.marklogic.com] On Behalf Of Clark Richey >>>>> Sent: Monday, October 11, 2010 2:06 PM >>>>> To: General Mark Logic Developer Discussion >>>>> Subject: Re: [MarkLogic Dev General] question about using same db or >>>>> separate db >>>>> >>>>> You could also use collections to separate the articles. That will allow >>>>> you to keep the URI's the same but keep the articles logically separated. >>>>> In the long run I think you will find that putting them in separate >>>>> databases will be more trouble than it's worth. >>>>> >>>>> ---- >>>>> >>>>> Clark D. Richey, Jr. >>>>> Principal Technologist, Federal >>>>> Mark Logic Corporation >>>>> 1600 Tysons Blvd >>>>> Suite 835 >>>>> McLean, VA 22102 >>>>> Phone: 240 - CLARK - 07 >>>>> (240 - 25275 - 07) >>>>> >>>>> clark.ric...@marklogic.com >>>>> >>>>> www.marklogic.com >>>>> >>>>> This e-mail and any accompanying attachments are confidential. The >>>>> information is intended solely for the use of the individual to whom it >>>>> is addressed. Any review, disclosure, copying, distribution, or use of >>>>> this e-mail communication by others is strictly prohibited. If you are >>>>> not the intended recipient, please notify us immediately by returning >>>>> this message to the sender and delete all copies. Thank you for your >>>>> cooperation. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 11, 2010, at 2:02 PM, helen chen wrote: >>>>> >>>>> >>>>> We have a system that needs to deal with articles going through staging >>>>> stage and production stage. Basically when article comes in, it stays in >>>>> staging stage. After a lot of operations and verifications the article >>>>> gets published, then at this time it will be moved to production stage. >>>>> The article's content can be changed during staging stage and can also >>>>> be changed when moving to production stage. >>>>> >>>>> I'm thinking of two ways to do it: >>>>> 1. One way is to put the data into separate directories within the same >>>>> database, like staging articles will be under /staging directory, >>>>> production articles will be under /prod directory. Using this way I only >>>>> need to manage one database, and maybe in the future if I need to search >>>>> data cross stage, it is doable. But inside code I have to constantly >>>>> check if I'm in staging stage or production stage so that my search or >>>>> article's uri will be build correctly. >>>>> >>>>> 2. Another way is to use different database for each stage. Using this >>>>> way the article's uri can be the same, a lot of code can be the same >>>>> because they will work in separate database, as long as database is >>>>> pointing correct, the code will return correct dataset. But if in the >>>>> future we ever want to do a search cross stage, it is going to be a >>>>> problem. >>>>> >>>>> Does anyone has any suggestions on this? >>>>> >>>>> Thanks in advance for your help, >>>>> >>>>> Helen >>>>> _______________________________________________ >>>>> General mailing list >>>>> General@developer.marklogic.com >>>>> http://developer.marklogic.com/mailman/listinfo/general >>>>> >>>>> _______________________________________________ >>>>> General mailing list >>>>> General@developer.marklogic.com >>>>> http://developer.marklogic.com/mailman/listinfo/general >>>> >>>> _______________________________________________ >>>> General mailing list >>>> General@developer.marklogic.com >>>> http://developer.marklogic.com/mailman/listinfo/general >>> >>> _______________________________________________ >>> General mailing list >>> General@developer.marklogic.com >>> http://developer.marklogic.com/mailman/listinfo/general >> >> _______________________________________________ >> General mailing list >> General@developer.marklogic.com >> http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > General@developer.marklogic.com > http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
