Mailing List Archive

Hi Bob,

I'm presuming that you added a serial number or something like that to
the tables that didn't have a primary key? Rather than turning some
existing field into a primary key.

The main problem with this might be that your database schema is
diverging from the standard DAViCal schema, and it might create a
conflict for you in a future schema upgrade. But if you needed to do
this perhaps it's something that should be added to the database schema
more generally. Can you share the tables you needed to add a key to,
perhaps as a set of SQL commands to upgrade from the standard schema to
the one you have? We can have a look and perhaps just incorporate this
into DAViCal.

-Jim

On 12/13/19 10:38 AM, Computerisms Corporation wrote:
> Hi List,
>
> We have been working towards a replication setup with something like
> bucardo.  The trick is that it seems any/all master-master replication
> methods with postgres requires that all tables have a primary key (or
> at least some kind of unique data) in order for them to work, and it
> turns out not all tables in davical have a such a thing.
>
> In testing, I was able to add primary key to all the tables in davical
> that didn't have one easily enough, and so far I can't find any
> problems resulting from doing that.  But before I put this into
> production I am just wondering if anyone has any reason to think this
> might be a bad idea?  For example, will future upgrades be a problem,
> or are any validation/integrity checks going to pop up and cause issues?
>
> Thanks for any thoughts you care to share.



_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hi Jim,

Thanks for the response.

> I'm presuming that you added a serial number or something like that to
> the tables that didn't have a primary key? Rather than turning some
> existing field into a primary key.

Yes, when looking through the tables I didn't find an appropriate field,
so adding a dedicated column seemed the smarter way to go. Also seemed
the least likely to conflict with anything future-wise.

> The main problem with this might be that your database schema is
> diverging from the standard DAViCal schema, and it might create a
> conflict for you in a future schema upgrade. But if you needed to do
> this perhaps it's something that should be added to the database schema
> more generally. Can you share the tables you needed to add a key to,
> perhaps as a set of SQL commands to upgrade from the standard schema to
> the one you have? We can have a look and perhaps just incorporate this
> into DAViCal.

What I will paste here is what my notes say I did for Bucardo a few
months back when I was testing things out; it turned out we had to do
similar with BDR from 2nd Quadrant as well. Column name should
definitely be something more generic. This was done on version 1.1.7, I
think.

alter table addressbook_address_adr add column bucardoid serial primary key;
alter table addressbook_address_email add column bucardoid serial
primary key;
alter table addressbook_address_tel add column bucardoid serial primary key;
alter table awl_db_revision add column bucardoid serial primary key;
alter table calendar_alarm add column bucardoid serial primary key;
alter table role_member add column bucardoid serial primary key;
alter table sync_changes add column bucardoid serial primary key;
alter table tmp_password add column bucardoid serial primary key;
alter table tz_aliases add column bucardoid serial primary key;
alter table tz_localnames add column bucardoid serial primary key;

Thanks for taking a look, truly appreciated!


>
> -Jim
>
> On 12/13/19 10:38 AM, Computerisms Corporation wrote:
>> Hi List,
>>
>> We have been working towards a replication setup with something like
>> bucardo.  The trick is that it seems any/all master-master replication
>> methods with postgres requires that all tables have a primary key (or
>> at least some kind of unique data) in order for them to work, and it
>> turns out not all tables in davical have a such a thing.
>>
>> In testing, I was able to add primary key to all the tables in davical
>> that didn't have one easily enough, and so far I can't find any
>> problems resulting from doing that.  But before I put this into
>> production I am just wondering if anyone has any reason to think this
>> might be a bad idea?  For example, will future upgrades be a problem,
>> or are any validation/integrity checks going to pop up and cause issues?
>>
>> Thanks for any thoughts you care to share.
>
>
>
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general
>


_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general