Re: [Opensync-devel] osync_archive_save_ignored_conflict()

[Chris F. <cd...@fo...>]

On Sun, Nov 08, 2009 at 05:14:23PM +0100, Daniel Gollub wrote:
> On Saturday 07 November 2009 12:58:38 am Chris Frey wrote:
> > Hi,
> > 
> > In the opensync_archive_internals.h header, _save_ignored_conflict()
> > is documented as such:
> > 
> > /**
> >  * @brief Saves an entry in the ignored conflict list.
> >  *
> >  * @param archive The group archive
> >  * @param objtype Reported object type of entry
> >  * @param mappingid Mapping Entry ID of entry
> 
> That's correct.

[...]

> > Isn't the entryid field used for the archive id's themselves, and not the
> > mapping ids?
> 
> Not quite sure which ID you mean for "archive id".

By "archive id" I'm referring to the IDs returned by the function
osync_archive_save_change(), which seems to be used in other functions
to refer to a row number in the tbl_changes table.

By "mapping id", I'm referring to IDs returned by the function
osync_mapping_table_get_next_id().

According to your email above, the ID in osync_archive_save_ignored_conflict()
is a mapping id.  This is what I was confused about.

It also seems like the id field in tbl_changelog is not used?


> While looking into this i found a bug in OpenSync which broke the support
> of "ignore conflicts". Which is hopefully fixed now with r5950
> 
> 
> Here is a dump of the tbl_changes and tbl_changelog, which contains two
> conflicts which got ignored. (I used for that a group with two file-sync members)
> 

[snip]

> 
> (changetypes: 3 == deleted, 4 == modified)
> 
> And indeed this looks pretty strange - 4 tbl_changelog for 2 mappings ...
> 
> The information is missing which member was sending which changetype ...
> 
> I guess it should look like this:
> 
> 
> ----8<---
> BEGIN TRANSACTION;
> CREATE TABLE tbl_changelog (objtype VARCHAR(64) NOT NULL, memberid INTEGER NOT NULL, mappingid INTEGER NOT NULL, changetype INTEGER NOT NULL, PRIMARY KEY (objtype, memberid, 
> mappingid) );
> INSERT INTO "tbl_changelog" VALUES('contact',1,4,4);
> INSERT INTO "tbl_changelog" VALUES('contact',2,4,4);
> INSERT INTO "tbl_changelog" VALUES('contact',1,6,4);
> INSERT INTO "tbl_changelog" VALUES('contact',2,6,3);
> COMMIT;
> ---->8---
> 
> 
> Does this sound sane?
> Does this address your question?

I'm sorry, but I don't fully understand the tables yet, so I can't
comment on whether it is sane.  It does look better that there are no
NULL values in the ID field.

My question was merely which ID belonged where, since I'm working on the
long long patch.

Thanks!
- Chris