Re: managing primary key conflicts while restoring data to table with existing data

From: Krishnakant Mane <kkmane(at)riseup(dot)net>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: managing primary key conflicts while restoring data to table with existing data
Date: 2019-09-25 11:46:56
Message-ID: bc684b8e-e84e-79e4-4a89-d616530bb40a@riseup.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On 25/09/19 4:32 PM, Rob Sargent wrote:
>
>
> On Sep 25, 2019, at 1:15 AM, Krishnakant Mane <kkmane(at)riseup(dot)net
> <mailto:kkmane(at)riseup(dot)net>> wrote:
>
>> Hello all,
>>
>> I have been using postgresql for an enterprise quality account's
>> automation and inventory management software called GNUKhata
>> <https://gnukhata.in>
>>
>> Our team is planning to add backup and restore function in the software.
>>
>> But we don't want to dump the entire database and then restore the same.
>>
>> What we are trying to do is to copy data specific to an organization.
>>
>> The challenge here is that I might copy all data (account heads,
>> bills, vouchers etc ) for one organization from an instance on one
>> machine.
>>
>> I take the archive in what ever format to another machine and now
>> attempt to restore.
>>
>> The risk here is for example if the primary key value for orgcode in
>> the organization table is 5, it might conflict with the data where I
>> am attempting it to be restored.
>>
>> Same holds true for bills, invoices etc.
>>
>> A certain account head with accountcode 1 might be already present on
>> the second machine.
>>
>> I am not expecting the users to empty all data from the destination
>> machine before restoring a backup.
>>
>> The reason is that an auditor may have many client's data and one
>> can't predict what primary key values are going to come from a backup.
>>
>> Basically I can even say this is a copy paste instead of a pure
>> backup and restore.
>>
>> Can any one suggest how to handle such conflicts?
>>
>>
>> --
>> Regards,
>> Krishnakant Mane,
>> Project Founder and Leader,
>> GNUKhata <https://gnukhata.in/>
>> //(Opensource Accounting, Billing and Inventory Management Software)//
> I’m not sure I like your definition of ‘backup and restore’ but you
> might get away with your approach if your keys were UUIDs. But I’ll
> bet dollars to doughnuts you’re using serial keys. Those seem to
> appeal to accounting types. 
--
Regards,
Hi Rob,
yes you are right, they are serial keys because timestamp or anything
thereoff is agressively despised by the accountants and the likes.
Now I am really stuck as to what could be done.Krishnakant Mane,
Project Founder and Leader,
GNUKhata <https://gnukhata.in/>
//(Opensource Accounting, Billing and Inventory Management Software)//

In response to

Browse pgsql-general by date

  From Date Subject
Next Message PegoraroF10 2019-09-25 13:38:50 Re: Operator is not unique
Previous Message Rob Sargent 2019-09-25 11:02:35 Re: managing primary key conflicts while restoring data to table with existing data