This is Issue 981 moved from a Google Code project.
Added by 2012-07-26T14:15:26.000Z by hachenb...@uni-koblenz.de.
Please review that bug for more context and additional comments, but update this bug.
Original labels: Type-Enhancement, Priority-Low
Sometimes databases have to be merged to one larger database. This means data is distributed over two or more databases which could also include data redundancy -- in case data is partially existing redundantly in two or more databases.
The example case:
For the sake of simplicity, let's assume a simple example where data is distributed over two databases WITHOUT any redundancy: Clusters 1,2,3 are in DB1 and 4,5,6 are in DB2 with no records or contents being duplicated/redundant.
Merging DB1 and DB2 is supposed to be done with using the "import database <filename>" command. First, DB1 is imported into a fresh (an empty) database or we just start from DB1 and would like to add DB2 contents to it.
When using the IMPORT command to date, we cannot carry out the example case as mentioned above. We get issues with the orginal RID being different from the RID in the destination database (no matter if this means DB1 or a fresh database!). This is the case since OrientDB seems to successively assign a new RID to clusters from the database to be imported (in our example this is DB2). However, this newly assigned RID is different from the original RID for some cluster. The original RID is stored in the export file (i.e. the JSON export).
Orientdb should do either of the two following options:
a) ignore original RIDs and continue with assigning RIDs during import
b) do not save RIDs with the export file and ALWAYS assign RIDs during import on the fly (in my opinion the way to go)