LinkDB: do not use raw timestamps to index links

[virtualtam]

Follow-up to: #347, #348
Relates to: #137, mro/Shaarli-API-test/issues/1
Impeded by: #324

Issue

Links are accessed using their timestamp, the format being YYYYMMDD_HHmmSS,thus, several links cannot be added during the same second.

Though this has no impact for users (one rarely is fast enough to click this fast), this prevents batch-adding links and stress-testing Shaarli in automated test suites.

Todo

• store links in a less restrictive way, e.g.
  • use an ID with no semantic value (DB-like)
  • use a more flexible key format: YYYYMMDD_HHmmSS_<id>
• handle migration to the new data format
• update client code

[nicolasdanelon]

if I'm importing a list of links from a Firefox backup or something is this issue related?
if you modify the actual database structure how will this touch the old saved links?

[virtualtam]

if I'm importing a list of links from a Firefox backup or something is this issue related?

Definitely:

• Firefox (Netscape) bookmarks should already have a date attribute
• there could be collisions (links added at the same second)
• though very unlikely, there may also be empty values

Regarding how it's handled when importing links in Shaarli, see index.php:

if (empty($raw_add_date)) $raw_add_date=time(); // In case of shitty bookmark file with no ADD_DATE
// Make sure date/time is not already used by another link.
// (Some bookmark files have several different links with the same ADD_DATE)
// We increment date by 1 second until we find a date which is not used in DB.
// (so that links that have the same date/time are more or less kept grouped by date, but do not conflict.)
while (!empty($LINKSDB[date('Ymd_His',$raw_add_date)])) { $raw_add_date++; }// Yes, I know it's ugly.
$link['linkdate']=date('Ymd_His',$raw_add_date);
$LINKSDB[$link['linkdate']] = $link;
$import_count++;

if you modify the actual database structure how will this touch the old saved links?

There are two possibilities:

• introduce a backward-compatible datastore format => old links are left unchanged
• adopt a new format => handle data migration

I'm not too fond of the second solution, as it implies keeping a compatibility layer, and is error-prone.

[ArthurHoaro]

Moving the milestone to 0.7.0 because that's something I'd like to see soon enough, and it's doable using the Updater class.