Thanks for the reply. Since these documents don't need to be added to an existing database, with existing security, I can try copying the security database across as you describe. I would then have the 2 security databases on hand if I need to migrate the documents to the correct IDs.
Cheers Gavin On 17 Sep 2012, at 18:52, "Michael Blakeley" <[email protected]> wrote: > Can you back up the Security database from the source system, and restore it > on the target system? This would mean overwriting any existing security > information on the target, which might also cause problems if an existing > application uses document permissions. > > You could also restore it into a new database, say "Security-dls". That > wouldn't interfere with your existing Security database, but would give you a > copy of the id-to-name mappings. If nothing else, you could use that database > for id-name mappings and write your own update code to perform the migration. > > If the source system is a different platform than the target, you could > export Security using XSQync and import it into a new database. I think it > would be risky to have XQSync import directly into the live Security > database, though. > > -- Mike > > On 17 Sep 2012, at 03:51 , Gavin Haydon wrote: > >> Hi, >> >> I have some documents that have been managed by DLS (Document Library >> Services) that I wish to transfer to another database. So far I have >> used xqsync to dump the documents to zip files, since xqsync retains the >> all important permissions and properties for you for every document. >> >> However, I foresee a problem when using xqsync to ingest these documents >> into a destination database on a separate MarkLogic instance. >> >> DLS has embedded the IDs of roles and permissions into the properties of >> each document. I believe this is so DLS can restrict access to the >> documents to 'dls users' but can still check the actual permissions of >> the user against these permissions stored in the properties. However >> these embedded permissions are using IDs that are specific to the >> Security database in effect for the content database. >> >> If I were to ingest these documents elsewhere, the IDs will not exist in >> the destination Security database. Therefore the DLS API will fail when >> it checks permissions on access to these documents. >> >> Has anybody come across this problem before and found a workable >> solution? I can only think of 'fixing up' the documents during the >> transfer to have the correct IDs for the destination, perhaps during >> load time or by using corb afterwards. I really don’t want the documents >> to go in with incorrect IDs. >> >> Regards, >> Gavin Haydon >> Press Association Ltd >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
