Proper UID Support for ical export (yokadid)

[bugzy]

Moving this discussion from #33 into its own issue
The UID exported for ical entries the should handle a use case where the yokadi is mainly being used for its convenient command-line interface to ical export.

For instance:
-User John creates databaseA with tasks and exports tasks to ical fileA
-User John creates databaseB with another set of tasks and exports tasks to ical fileB
-User John imports fileA and fileB into the same ical aware program

With the current code imported tasks from fileB will conflict with imported tasks from fileA, because project UIDs and task UIDs from both files will either be the same or will overlap.

@digitalfox suggested:
About UUID, I am afraid that your change (bugzy@09e71b6) has some side effects. If you stop/start yokadid, it generates new UUID and tasks wiil looks like new ones.
We may need a uniq database id that should prefix projects and tasks, but it needs to be persistant and constant. Maybe in the config table ?

@agateau says:
Regarding UUID: this is something I have been willing to add for a long time, but I think it should be in the table of the related elements (Task.uid, Project.uid...). I would keep those changes out for now.

[agateau]

Python provides a uuid module which I assume (never used it) could be use to populate new uid columns in the tables which require them. Right now we have the following tables:

• Task
• Project
• Keyword
• ProjectKeyword
• TaskKeyword
• Recurrence
• Config

One of my main (ambitious) goals for Yokadi is to implement synchronization, so that you can run Yokadi on your laptop and sync it with a Yokadi installation on your server. A necessary building block for this to work is to have unique id for all Yokadi "entities".

On the other hand, as far as I understand it, you are mainly interested in ensuring icalendar exports do not create conflicts, which means you only need unique ids for tasks, is this correct?

If so, I would suggest giving a try at adding an "uid" column to Task first, filled with uuid.uuid4() and use this uid in the ical code. This would give us good feedback on the potential drawback of this approach before generalizing it to other tables.
As far as I understand it,