LinkDB: do not use raw timestamps to index links
Closed this issue · 3 comments
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
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?
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.
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.