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

[IwantToKeepAnon <iwanttokeepanon at yahoo dot com>]

"Marco van Beek" <marco@84andahalf.com> writes:

> 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.

You assume that a user will *never* want to sync with
the Palm desktop or at home or with a memory stick,
etc...

Here's a snip from 'DmSetRecordInfo' documentation ...
   Normally, the unique ID for a record is
automatically created by the data manager when a
record is created using DmNewRecord(), so an
application _would not typically change the unique
ID_.

You are going against "best practices" and you should
be very careful.  Since all new records are going to
be assigned an ID via the Palm OS, it ONLY guaranties
an ID to be unique with respect to its own IDs.  What
happens when Palm OS picks an ID your MySQL database
generated?  Data loss?  Boom?

> 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.

There in lies the rub ... it is *not* MySQL's job but
the device's job.  Do you have users on Palm OS 3, 4,
and 5?  Do you have users on Palm mXXX, Clie,
HandSpring, etc...?  Just "I haven't seen a problem"
doesn't make good design.  It just may mean you are
lucky ;-)

> 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.

I hardly think a key with 1 integer vs. a key with 2
integers complicates things at all.  If it does, just
make the MySQL id a "long long" and shift the user id
in front of the unique record ID.

*If* you stay with the "change the ID" method, at
least use something like 'DmSetRecordInfo' to change
the ID and save the upload/delete/download step.

> 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.

I agree that perl sync conduits are too scarce.  I
have a generic perl sync conduit in the works.  So it
uses DLP/SPC and Palm::PDB already.  It can iterate
over dirty records, all records, etc...  I have been
working on a SF.net project for the last couple of
months and I havn't added the spit and polish I need
before releasing it.  But if you are interested, reply
privately and I'll send you a copy.

Keep hacking ...

=====
-- 
"A smile is the shortest distance between two people."
Victor Borge

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
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.