-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firefox/chrome: support from_visit
field
#30
Comments
Ah -- yeah, somewhat similar to #16 in complexity, as that requires 'merging' the results back into a database, which would require mangling the It does become pretty useless across exports -- maybe it would be better to resolve the So you'd have something like:
Could also expose the id, but I think promnesia gets the same improvement if its the URL Remapping the IDs in browserexport sounds like a pain... would make this less functional and require connecting lots of internal state, which is a similar reason to why I've put #16 on low prio. |
Ah, the reason I was thinking of ids is because it might be interesting to trace through visits via But tbh, it's worth just playing with the databases and checking first -- seems that |
I think it may depend on the visit_type (in firefox at least). It would only be set if |
Might be potentially interesting for Promnesia. Although also possible that the utility is very marginal and traversing history by timestamps is good enough.
moz_historyvisits.from_visit
. On mobile the field is present but seems to always beNULL
visits.from_visit
Perhaps belongs to
metadata
, but also means that we'd need to keep original visit ID from the sqlite database to match the visit. And even worse, when all visits from different historic exports are merged in a single stream, the ids don't make sense anymore (they are 'internal' to a specific export in general). Although this would be possible to workaround if we somehow remap the ids in browserexport itselfThe text was updated successfully, but these errors were encountered: