-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Dgraph exported data with original UIDs #2934
Comments
Let's support this. This situation comes up enough that preserving UIDs in exports should be the default. There can also be an options to not preserve UIDs for backward compatibility. Live Loader and Bulk Loader should correctly handle UID literals in the exported RDFs. |
I would actually vote for keeping the blank UIDs as the default in order to discourage thinking that they will be preserved when the export is reloaded. |
Yeah, me too. Cuz the binaries backup that Guz is working on already does this job. And this could be problematic for "Live Load". If this were adopted by Live Load. For a DB that is already in use, may end up being overwritten on the hypothesis of a load the RDF with predetermined UIDs. It could be catastrophic. Maybe not for BulkLoad, but for Live load it certainly does. This could be useful in a controlled ingestion hypothesis and the user would assume the risks of having the overwritten data. But it would not be safe in the hypothesis of exporting to a DB in use. |
Sorry, I didn't see these comments before. I can explain why the UID
exports make sense, instead of blank nodes.
Sent from Pixel 2
…On Mon, Feb 11, 2019, 4:14 PM Javier Alvarado ***@***.*** wrote:
Closed #2934 <#2934> via #3004
<#3004>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2934 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABsyNLSKATJBZ78Lcdn27hPmQpOKtSwDks5vMgd8gaJpZM4aSG5Q>
.
|
Experience Report
often use fixed UID to process the data. When upgrading the database, when exporting the data, it is found that the exported .rdf file uses an identifier instead of the original UID. The resulting exported data is not directly usable.
What you wanted to do
Provide a data to configure the export database by fixed UID
What you actually did
I find worker/export.go has code for export database
fmt.Sprintf("<_:uid%x>", p.Uid);to fmt.Sprintf("<_0x%x>", p.Uid)
Why that wasn't great, with examples
UID consistency cannot be guaranteed when restoring database data
Any external references to support your case
none
The text was updated successfully, but these errors were encountered: