I have a large database (27+ GB) that I’d like to split in two. It consists of two main folders (one 20+ GB, the other 7 GB), so division is easy.
The trouble is that I have multiple replicants in both folders – replicating files from the other main folder. So I can’t simply drag & drop folders to a new database, or I’ll break those links.
I think I have the solution, but wanted to confirm first with the community:
1 / Find all replicants in the whole database.
2 / Convert them all to duplicates.
3 / Then move the folders as needed.
How else would you do it? Any way to isolate just the replicants in the other main folder? (That might be too much to ask.)
With sufficient disk space I’d make a duplicate copy of the database (e.g. using File > Duplicate [Command-D] in Finder), rename the file and change its db Name under Dt > File > Database Properties…, then remove the unneeded group from each db to achieve the desired splitting result without the hassle of converting replicants to duplicates.
Revised my thoughts here – see the downstream postings in this thread
The problem is, making replicants into duplicates is time consuming because you need to locate each of them. The scripting dictionary for DEVONthink does not seem to provide a simple approach to automate the task (like it does for duplicates), and when you use a Smart Group to locate “instance is replicant” the result is only one of the replicants, not all of them. The reason is that a replicant is merely a pointer to the single instance of that document in the database.
Once you locate a replicant, duplicating it is easy: command-D to make the duplicate, then delete the replicant from the containing group.
Thanks for affirmation, removing doubts I’d overlooked something.
[Edit: I overlooked the duplicate UUID issue, which Shoolie fortunately brought to everyone’s attention.]
So, do results of a Smart Group match for replicants always display the “single instance of that document” version of the replicant rather than any pointer versions of it? What happens when the former is deleted; does one of the pointers become the new “master instance”? Or am I confused?
It’s unfortunate there’s still no easier way (AFAIK) to find all instances for each replicant than repeatedly using Go > (Previous|Next) Instance commands. I wish Dt replicants were “internally” identical like Unix/POSIX hard links essentially are.
Wouldn’t this practice result in two databases with the same UUID? This tripped me up a while back (“Sorter: Contents change spontaneously,” [url]Sorter: Contents change spontaneously]).
Create a new database and copy everything from the curated database over and delete the database with the same UUID.
That should solve the problem (if it is a problem).
If a database has two groups A and B, and those groups have the a replicant of the same item, then dragging those groups to another database will retain the replicants – they will show up in the new location as replications. On the other hand if groups A and C have a replicant in common then dragging A but not C to the new database will result in the replicant that was in C being lost. If groups A, B and C have a common replicant then moving A; or A & B; or C; or B & C – but not A & B & C – will result in lost replicants in the original database. Either move all replicants or none, it seems.
If export each Group to the filesystem using ‘Files>Export>Files and Folders…’, the all the replicants will be exported out as documents. When you import them into a new database using ‘Files>Export>Files and Folders…’ all the documents will be imported, and replicated in the database because of the information stored in the ‘DEVONtech_storage’ that is exported out with the files and folders.
In other words, if I have Database A with two groups containing the following:
GroupA
documentA ⧉
I export, using ‘Files>Export>Files and Folders…’, GroupA to the Finder.
I also export GroupB to the Finder.
In the Finder, I see the following files and folders:
GroupA
DEVONtech_storage
documentA
Sub-GroupA
documentA
GroupB
DEVONtech_storage
documentA
Sub-GroupB
documentA
If I create 2 new databases, named ‘DB2A’ and ‘DB2B’, and import, using ‘Files>Import>Files and Folders…’, the Finder folder GroupA into 'DB2A and the Finder folder GroupB into 'DB2B, then the two databases look like this:
Database ‘DB2A’
GroupA
documentA ⧉
Sub-GroupA
documentA ⧉
and
Database ‘DB2B’
GroupA
documentA ⧉
Sub-GroupB
documentA ⧉
The documentA, which was a replicant in 4 locations in the original database, now appears in both databases, replicated in 2 locations. It should be obvious, but documentA is not a replicant across the databases. If you change an instance of documentA in one database, those changes will not be reflected in the other database.
If Groups containing “originals” are moved along with the Replicants then the Replicants are maintained in the destination database.
Note that the scope of Replicants being local to the database, they MUST be moved in concert or they will “disappear”.
Say I have two Replicants in two different folders and one loose in a DB. If I move the loose one into another DB alone, the other Replicants will disappear. This is easily verifiable behavior.
Again, many thanks. I’ve followed Prion’s advice and the Sorter is happy to distinguish between the two inboxes.
Someday, perhaps, a future update will permit replicants across databases. Until then, I use the ‘Copy item link’ function & pasting it (as a bookmark) into the other database(s) as needed.
A little bit of a twist on this is that if A, B and C are groups with a replicant in common, moving A and B will retain replication in the destination database but C (which stayed behind in the source database) will lose its document.
That is true, which is also why in the example I gave, I suggested exporting out both groups and creating two new databases, instead of exporting out one group and then deleting said group from the original database. It also gives an additional layer of protection that the original database remains intact in case something goes wrong with the export/import.
Got any examples of negative side effects when dbs have duplicate UUIDs besides confusing Sorter (which I don’t use) and probably Sync (which I do use)?
Why is the db UUID retained when changing the db Name in Database Properties? Even if renaming a db that way gave it a new UUID presumably there can be issues with UUID duplicates for records?
Looks like duplicating dbs at the filesystem level is tempting trouble. Sorry for suggesting that to you, Michael.
Because the name is just a bit of convenience metadata while the UUID is exactly that - a unique identifier. Admittedly, this is a strange situation form a User perspective since we think in human-readable metadata but this is pretty common logic under-the-hood of many modern OS X apps (iCal/Calendar and Mail.app are two examples).
Yes this would affect Sync since the UUID is referenced (check out the Dropbox Apps/DEVONthink/databases folder). Also, DEVONthink might (and should) squawk at you that the database is already opened if the original is open (and potentially if it’s closed).
Creating/using duplicates of something’s that’s unique doesn’t seem like “common logic” (to me), uhh, maybe for under-the-hood logic.
It’s tempting (for me) to think of UUIDs being unique like serial numbers, forgetting their attributes of uniqueness can differ. UUID duplication/reusage is useful and intended in normal situations; I can’t think of cases when duplicate serial#s would be.
I knew Sync relies on db UUIDs.
I might be able to figure out answers to some questions about record UUID handling.
Looking at your initial comment… You are talking about changing the name in DEVONthink, so why would it change the UUID that is generated when the database is created? The name is meaningless (except for the convenience factor for us being human ).
You can’t duplicate the DB in DEVONthink (though this smells like an interesting concept/opportunity, in some obtuse way ). Duplicating it in the Finder has no intimate connection with DEVONthink so it just makes a file with the same inherited properties of the original.
).
). Duplicating it in the Finder has no intimate connection with DEVONthink so it just makes a file with the same inherited properties of the original.