Re: [coldsync-hackers] Design logic of Sync conduits

[Marco van Beek <marco at 84andahalf dot com>]

Hi,

> Can I interject?  This seems like a "bad idea"(tm). 
> This means that :
>   (1) I create a record
>   (2) I sync it
>   (3) you delete it
>   (4) you upload it as a new record (ie. dirty)
>   (5) I sync it again
>
> Is that right?
>

The theory is that if I can keep a unique {id} across all the PDA's, I 
don't have to keep track of multiple id's for multiple PDA's.

If a record is created in MySQL, it gets a unique id that can be 
downloaded to all the PDA's, and (usual conflict resolutions apart) can 
therefore be used to update any changes.

If the PDA creates the record, it adds it to MySQL, but without the id 
number. Under my current fetch, dump system, it takes a fetch (which is 
a second sync) to "add" the new record to the PDA, and to delete the old 
one. Which is unsatisfactory, hence wanting to use a sync conduit where 
I can do it all at once. Which a sync conduit I can lock the MySQL 
tables so that nothing else can interfere with the process.

> Thats 3 complete transfers where only 1 is needed. 
> When you create a
> record, Palm allows you to specify an id; but I think
> their docs say
> *not* to.

So far I haven't seen a problem. I agree it is a _bad_ idea in the 
conventional sense, but the MySQL server is supposed to be doing the job 
of ensuring a unique id. The reason I would prefer to load the PDA 
records into MySQL first, is that this way hopefully we reduce the 
possibility that the new MySQL id overwrites any PDA records.

> I think your DB model may need fixing and not the sync
> process.  If
> you need to track multiple handhelds/users, just make
> the table and/or
> keys reflect that.

I am also tracking each record by owner (based on who added the record) 
and I use this mainly for privacy, and for the Calendar where we are 
only downloading our own records. In fact, I am thinking about adding an 
ALL user so that we do not end up with multiple copies of holidays, etc.

> Ie. for 1 user: PK = record id; works fine.
> for 2 users: PK = user id+record id; or PK = record
> id+user id
>
> You just need to add user id to the MySQL table.
>
> Lastly the "(assuming it hasn't been changed)" is a
> big gap that I
> would not be comfortable with and I wouldnt use a
> conduit that
> read/wrote a single record 3 times.

Hopefully, only doing the one sync with table locks will mean that we 
can rely on that assumption.

> .... Just my 2 cents.
>
> =====

The four Palm fetch/dump conduits have been my first venture into Perl 
programming. There are many things I don't fully understand, and this 
has also been my first PDA project as well! Everyone I have spoken to 
has been very helpful.

The basic fetch/dump system has been running since August, and it would 
appear that it would have been much simpler to have written a sync 
conduit rather than a fetch/dump where I have had to compare data to see 
if records had changed.

If I can get enough guidance (and Christophe has been really helpful) to 
get started, I may end up with an PDA application specific DBI based 
conduit that could have may applications, since I have tried to keep the 
MySQL database as comparable to the PDA structure as possible.

Thanks,

Marco.
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.